feat(eks): eks pod identities

[pahud]

This PR introduces EKS Pod Identities support.

Amazon EKS introduced IRSA in 2019 for fine grained iam roles service accounts support. In aws-eks, we have ServiceAccount construct that implements IRSA under the hood and creates OpenIdConnectProvider for the cluster. In 2023, Amazon EKS introduced EKS Pod Identities as a new way for applications on EKS to obtain IAM credentials.

This PR introduces a new identityType prop for ServiceAccount to allow users to opt in the EKS Pod Identities. When you opt in POD_IDENTITY:

1. ServiceAccount would NOT create any OpenIdConnectProvider.
2. An IAM role with trust policy for pods.eks.amazonaws.com service principal would be created.
3. EKS Pod Identity Agent for the cluster would be provisioned as an Addon if not exist.
4. CfnPodIdentityAssociation would be created for the role and service account.

Sample

declare const cluster: eks.Cluster;

new eks.ServiceAccount(this, 'ServiceAccount', {
  cluster,
  name: 'test-sa',
  namespace: 'default',
  identityType: eks.IdentityType.POD_IDENTITY,
});

// deploy a sample pod
const pod = cluster.addManifest('demopod', {
  apiVersion: 'v1',
  kind: 'Pod',
  metadata: { name: 'demo' },
  spec: {
    serviceAccountName: sa.serviceAccountName,
    containers: [
      {
        name: 'demo',
        image: 'public.ecr.aws/amazonlinux/amazonlinux:2023',
        command: ['/bin/bash', '-c', 'yum update -y && yum install -y awscli && aws sts get-caller-identity'],
      },
    ],
  },
});
pod.node.addDependency(sa);

Todo Checklist

• Addon L2 construct
• Update ServiceAccount construct
• unit tests
• integ test(s)
• update README

Callout

1. According to the doc, the assume role policy of the role is having both sts:AssumeRole and sts:TagSession but the iam.Role construct only allows sts:AssumeRole assumeRoleAction and no way to customize it on Role creation.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}

As a workaround, this PR assumeRolePolicy.addStatements() to create a new statement for the assumeRolePolicy. Definitely should improve this if we have a better solution.

role.assumeRolePolicy!.addStatements(new PolicyStatement({
        actions: ['sts:AssumeRole', 'sts:TagSession'],
        principals: [new ServicePrincipal('pods.eks.amazonaws.com')],
      }));

2. We should scope down the trust policy with conditions for sts:TagSession but it's not clear to me what is the recommended conditions for that. Need to discuss with EKS team. Per doc describes:

EKS Pod Identity uses TagSession to include session tags in the requests to AWS STS.
You can use these tags in the condition keys in the trust policy to restrict which service accounts, namespaces, and clusters can use this role.
For a list of Amazon EKS condition keys, see Conditions defined by Amazon Elastic Kubernetes Service in the Service Authorization Reference. To learn which actions and resources you can use a condition key with, see Actions defined by Amazon Elastic Kubernetes Service.

Issue # (if applicable)

Closes #30519

Reason for this change

Allow users to opt in EKS Pod Identities.

Description of changes

Description of how you validated changes

Unit tests and integ test.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[pahud]

@Mergifyio refresh

[mergify]

refresh

✅ Pull request refreshed

[nnmin-aws]

/lgtm

[GavinZZ]

LGTM, one minor comment before approving

[pahud]

Will update my tests to include addonVersion

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 65f99dc
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

Comments on closed issues and PRs are hard for our team to see. If you need help, please open a new issue that references this one.