Remove obsolete securityContext step from Route53 IRSA guide - #2228
Remove obsolete securityContext step from Route53 IRSA guide#2228wallrj wants to merge 2 commits into
Conversation
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#697. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Richard Wall <richard@the-moon.net>
cert-manager-prow
Bot
added
the
dco-signoff: yes
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
cert-manager-prow
Bot
added
the
size/M
✅ Deploy Preview for cert-manager ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Pull request overview
This PR updates the Route53 DNS01 “EKS IAM Role for Service Accounts (IRSA)” guide to remove an obsolete optional securityContext workaround, replacing it with an explanatory note and pointers for legacy EKS/Fargate cases.
Changes:
- Removes the optional “Update file system permissions” step that suggested setting
runAsUser/fsGroup. - Adds a short explanatory note referencing Kubernetes 1.19+ projected ServiceAccount token permissions and links to issue #697 for legacy/Fargate troubleshooting.
- Renumbers the subsequent steps accordingly.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| > 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). |
There was a problem hiding this comment.
Fair point — reworded in 2ebde17: the claim is now scoped to Kubernetes >= 1.19, and the note tells readers who still hit the permission error to apply the securityContext as a workaround.
with claude fable-5
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 <noreply@anthropic.com> Signed-off-by: Richard Wall <richard@the-moon.net>
Preview: https://deploy-preview-2228--cert-manager.netlify.app/docs/configuration/acme/dns01/route53/#eks-iam-role-for-service-accounts-irsa
Removes the optional "Update file system permissions" step from the Route53 IRSA guide and replaces it with a short note for anyone still on an old EKS version or EKS Fargate.
Fixes #697
The step asked readers to tell us whether it was still necessary. In the latest comment on #697, @av-rasmus confirms that cert-manager v1.21.1 on EKS 1.36 works with Route53 IRSA without changing the
securityContext. This matches @TBBle's analysis in #1555 (comment): since Kubernetes 1.19, the projected ServiceAccount token file is world-readable (0644) when the Pod does not setrunAsUser, and cert-manager runs as non-root by default.Prior art: the step and the request for feedback were added in #1555.
with claude fable-5