aws / aws/containers-roadmap

[EKS] [request]: Use An External OIDC Issuer With The IRSA Role

Open
#1,579 0 comments 46 reactions 0 assignees View on GitHub
EKS Proposed
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.