Describe the feature

Amazon EKS, a managed Kubernetes service on AWS, introduced a new feature called EKS Pod Identity at the 2023 re:Invent conference. This feature simplifies the management of AWS credentials for applications running in Kubernetes pods. [1]

Previously, the IAM Roles for Service Accounts (IRSA) feature was used to associate IAM roles with Kubernetes service accounts, allowing pods to obtain AWS credentials. However, IRSA required cluster administrators to set up and maintain an OIDC identity provider. [2]

EKS Pod Identities eliminate the need for an OIDC provider by introducing a new EKS service principal called pods.eks.amazonaws.com. This allows IAM roles to be directly associated with Kubernetes service accounts, providing several benefits:

Independent operations: Cluster administrators can manage IAM roles and service account associations independently, without needing to coordinate with IAM administrators.

Reusability: IAM roles can be reused across multiple clusters without updating the trust policy when creating new clusters.

Scalability: EKS Pod Identity supports IAM role session tags, enabling fine-grained access control based on attributes like namespace, service account, and pod metadata.

Overall, EKS Pod Identity simplifies the management of AWS credentials for Kubernetes applications, improving the developer experience and enhancing the security and auditability of the system.

AWS CDK introduced the IRSA support for Amazon EKS in 2020. By creating the ServiceAccount contruct, aws-eks would create an OpenIdConnectPrincipal with a new cluster.openIdConnectProvider being created under the hood, which is no longer required for EKS Pod Identities.

Use Case

To simplify the pod identities association experience without handling and operating OIDC IdP.

Proposed Solution

I would suggest adding a new enum to the ServiceAccountProps
interface. This enum would allow users to choose between the existing IRSA (IAM Roles for Service Accounts) approach and the new EKS Pod Identity feature. [1]

When users select the EKS Pod Identity option, the ServiceAccount construct would handle the necessary configuration behind the scenes, no OIDC identity provider would be provisioned and required PodIdentityAssociation would be created automatically. This would simplify the user experience and eliminate the need for them to manage the identity association and policies of the pod principal.

I would investigate the feasibility of implementing this enhancement to the AWS CDK library, as it could provide a more seamless integration of the EKS Pod Identity feature and improve the overall developer experience when working with Kubernetes on AWS. [3]

Other Information

EKS Pod Identities
https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html
Benefits of EKS Pod Identities
https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-benefits
Overview of setting up EKS Pod Identities
https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-setup-overview
EKS Pod Identity considerations
https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-considerations
A deep dive into simplified Amazon EKS access management controls
https://aws.amazon.com/blogs/containers/a-deep-dive-into-simplified-amazon-eks-access-management-controls/
Amazon EKS Pod Identity: a new way for applications on EKS to obtain IAM credentials
https://aws.amazon.com/blogs/containers/a-deep-dive-into-simplified-amazon-eks-access-management-controls/

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

all

Environment details (OS name and version, etc.)

all