From 56c084460f5320bad61126d44cea0c2a61f5381a Mon Sep 17 00:00:00 2001 From: Richard Wall Date: Mon, 10 Aug 2026 13:13:52 +0100 Subject: [PATCH 1/2] Remove obsolete securityContext step from Route53 IRSA guide Since Kubernetes 1.19 the projected ServiceAccount token file is world-readable when the Pod does not set runAsUser, so changing the cert-manager user and group is no longer necessary. Confirmed on EKS 1.36 with cert-manager v1.21.1 in cert-manager/website#697. Co-Authored-By: Claude Fable 5 Signed-off-by: Richard Wall --- .../docs/configuration/acme/dns01/route53.md | 50 ++++++------------- 1 file changed, 14 insertions(+), 36 deletions(-) diff --git a/content/docs/configuration/acme/dns01/route53.md b/content/docs/configuration/acme/dns01/route53.md index 0bd2d79c185..1562341ad5e 100644 --- a/content/docs/configuration/acme/dns01/route53.md +++ b/content/docs/configuration/acme/dns01/route53.md @@ -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. + > This is no longer necessary. + > Since Kubernetes 1.19, 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. + > If you see errors such as + > `open /var/run/secrets/eks.amazonaws.com/serviceaccount/token: permission denied` + > on an old EKS version or on EKS Fargate, + > read [`cert-manager/website#697`: IRSA Needs `runAsUser: 1001`](https://github.com/cert-manager/website/issues/697). + +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 From 2ebde17d1dcc90a66f3a11b5fd66ef1dc5cc9e58 Mon Sep 17 00:00:00 2001 From: Richard Wall Date: Mon, 10 Aug 2026 13:56:41 +0100 Subject: [PATCH 2/2] Scope the securityContext note to Kubernetes >= 1.19 Address Copilot review: avoid the absolute claim that the workaround is never needed, since it has been reported necessary on older EKS versions and on EKS Fargate. Co-Authored-By: Claude Fable 5 Signed-off-by: Richard Wall --- content/docs/configuration/acme/dns01/route53.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/docs/configuration/acme/dns01/route53.md b/content/docs/configuration/acme/dns01/route53.md index 1562341ad5e..728263b3d11 100644 --- a/content/docs/configuration/acme/dns01/route53.md +++ b/content/docs/configuration/acme/dns01/route53.md @@ -236,14 +236,14 @@ A mutating webhook will automatically setup a mounted service account volume in > ℹ️ 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. - > This is no longer necessary. - > Since Kubernetes 1.19, the + > 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. - > If you see errors such as - > `open /var/run/secrets/eks.amazonaws.com/serviceaccount/token: permission denied` - > on an old EKS version or on EKS Fargate, - > read [`cert-manager/website#697`: IRSA Needs `runAsUser: 1001`](https://github.com/cert-manager/website/issues/697). + > 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**