[EKS] [request]: Use An External OIDC Issuer With The IRSA Role
- Dominant language
- Shell
- Stars
- 5.4k
- Forks
- 334
- PR merge metrics
- No merged PRs in 30d
Description
### Community Note
* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment
**Tell us about your request**
_Submitted on behalf of a customer._
A way to use an external OIDC Issuer that can be attached to a cluster post-provisioning so the IRSA Role can be configured to trust the external/persistent OIDC Issuer.
**Which service(s) is this request for?**
EKS
**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
The customer is configuring their IAM Roles via Terraform. Each of their development teams is responsible for configuring their own IAM Roles/Profiles. If a cluster is torn down and recreated (for example, due to blue/green testing or failover) the new cluster has a new OIDC Issuer. If an application is referencing the old OIDC Issuer it will break. All teams using IRSA have to re-run their Terraform with the properties from the new OIDC Issuer that is created.
**Are you currently working around this issue?**
Re-run their Terraform plans.
**Additional context**
None
**Attachments**
None
Contributor guide
Research direction
No repository files, tests, or implementation entry points are named. Start by reviewing the EKS and IRSA requirements in the issue, then determine how an external, persistent OIDC issuer could be attached after cluster provisioning and trusted by Terraform-managed IAM roles. Done means the requested behavior and its effect on cluster recreation are clearly defined and validated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, kubernetes, terraform
- Domain
- authentication, authorization, cloud
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100