Skip to content

Remove obsolete securityContext step from Route53 IRSA guide #2228

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wallrj wants to merge 2 commits into
base: master
Choose a base branch
from
+14 −36
Open

Remove obsolete securityContext step from Route53 IRSA guide #2228

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
56c0844
Remove obsolete securityContext step from Route53 IRSA guide
wallrj Aug 10, 2026
2ebde17
Scope the securityContext note to Kubernetes >= 1.19
wallrj Aug 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 14 additions & 36 deletions content/docs/configuration/acme/dns01/route53.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -233,46 +233,24 @@ A mutating webhook will automatically setup a mounted service account volume in

> ℹ️ If you're following the Cross Account example, modify the `ClusterIssuer` with the role from Account Y.

4. **(optional) Update file system permissions**

> 📢 **Please help us improve this documentation**
>
> The reason for this optional step is that on EKS Fargate and on some
> older versions of EKS you may observe errors such as:
> - `unable to read file at /var/run/secrets/eks.amazonaws.com/serviceaccount/token`
> - `open /var/run/secrets/eks.amazonaws.com/serviceaccount/token: permission denied`
>
> In this case, you can change the user and group of the cert-manager process
> so that it is able to read the mounted ServiceAccount token.
>
> Read [`cert-manager/website#697`: IRSA Needs `runAsUser: 1001`](https://github.com/cert-manager/website/issues/697)
> and tell us whether this step is still necessary or obsolete.

You may also need to modify the cert-manager `Deployment` with a different user and group, so the `ServiceAccount` token can be read.

```yaml
spec:
template:
spec:
securityContext:
fsGroup: 1001
runAsUser: 1001
```

The cert-manager Helm chart provides a variable for modifying cert-manager's `Deployment` like so:

```yaml
securityContext:
fsGroup: 1001
runAsUser: 1001
```

5. **Restart the cert-manager Deployment**
> ℹ️ Older versions of this guide included an extra step here:
> setting `runAsUser: 1001` and `fsGroup: 1001` in the `securityContext` of the cert-manager `Deployment`,
> so that the cert-manager process could read the mounted ServiceAccount token.
> On Kubernetes >= 1.19 this should not be necessary, because the
> [projected ServiceAccount token file is world-readable](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1205-bound-service-account-tokens#file-permission)
> when the Pod does not set `runAsUser`, and cert-manager runs as a non-root user by default.
> But if you see errors such as
> `open /var/run/secrets/eks.amazonaws.com/serviceaccount/token: permission denied`,
> which have been reported on older EKS versions and on EKS Fargate,
> apply that `securityContext` as a workaround and read
> [`cert-manager/website#697`: IRSA Needs `runAsUser: 1001`](https://github.com/cert-manager/website/issues/697) for the background.

4. **Restart the cert-manager Deployment**

Restart the cert-manager Deployment, so that the webhook can inject the
necessary `volume`, `volumemount`, and environment variables into the Pods.

6. **Create a `ClusterIssuer` resource**
5. **Create a `ClusterIssuer` resource**

```yaml
apiVersion: cert-manager.io/v1
Expand Down