Skip to content

Commit

Permalink
feat(eks): eks pod identities (#30576)
Browse files Browse the repository at this point in the history
This PR introduces [EKS Pod Identities](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html) support.

Amazon EKS introduced [IRSA](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) 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](https://github.com/aws/aws-cdk/blob/b196b13b0b8a54dcacadf87fdbe744772a6e6c4d/packages/aws-cdk-lib/aws-eks/lib/oidc-provider.ts#L36) for the cluster. In 2023, Amazon EKS [introduced](https://aws.amazon.com/blogs/containers/amazon-eks-pod-identity-a-new-way-for-applications-on-eks-to-obtain-iam-credentials/) 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](https://github.com/aws/aws-cdk/blob/b196b13b0b8a54dcacadf87fdbe744772a6e6c4d/packages/aws-cdk-lib/aws-eks/lib/oidc-provider.ts#L36).
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

```ts
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

- [x] Addon L2 construct
- [x] Update ServiceAccount construct
- [x] unit tests
- [x] integ test(s)
- [x] update README

### Callout

1. According to the [doc](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html#pod-id-association-create), 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](https://github.com/aws/aws-cdk/blob/b196b13b0b8a54dcacadf87fdbe744772a6e6c4d/packages/aws-cdk-lib/aws-iam/lib/role.ts#L373) it on Role creation. 
```json
{
    "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.

```ts
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](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html) 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](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) 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](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).


### 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
- [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
  • Loading branch information
pahud committed Jun 27, 2024
1 parent e09126f commit 9437b4d
Show file tree
Hide file tree
Showing 62 changed files with 17,342 additions and 68 deletions.

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Loading

0 comments on commit 9437b4d

Please sign in to comment.