More support of PodIdentityAssociations

[ardens-jw]

Describe the feature

Looking into the repository I can only see one example of PodIdentityAssociations and it appears to be for the karpenter add-on.

Reading the AWS docs - they suggest the recommended way of setting up authentication to AWS APIs for workloads within the cluster is using the EKS Pod Identity agent, as opposed to IAM Roles for Service Accounts.

Is there any way I can implement this myself via overrides?

Use Case

Just curious if this will be supported in the future!

Proposed Solution

No response

Other Information

No response

Acknowledgements

• I may be able to implement this feature request

CDK version used

N/A

EKS Blueprints Version

No response

Node.js Version

N/A

Environment details (OS name and version, etc.)

N/A

[shapirov103]

@ardens-jw if your use case is creating pod identity association for workloads then our recommended approach is using GitOps and crossplane to create podidentity associations (or ACK + kro), e.g. something similar to what we implemented in our platform engineering on EKS initiative: https://catalog.workshops.aws/platform-engineering-on-eks/en-US/30-applicationdelivery/01-section1-rust/04-cd.

However, if you would like to use blueprints to deploy your workloads or to create IRSA/PodIdentity directly, we can add this support. If you plan to use it with teams, please let us know, we can provide a way to create namespace, sa and pod identity association.

in the interim, blueprints.utils.podIdentityAssociation function is exported and can be used directly. You can extend the ApplicationTeam class and override the setupServiceAccount method to create pod identity association instead (this method creates IRSA now).

[ardens-jw]

Thanks for your reply - really useful insight. I'm interested in using these blueprints to standup a handful of different clusters and would prefer to use Pod Identities for the addons - e.g. for the VPC CNI, EBS CSI etc. It seems as though they are currently only supporting IRSA - unless you know of a way to override the behaviour?

[shapirov103]

I see, I misinterpreted the kind of workloads you had in mind. For existing addons the aspect of how the service account was created was not approached as an extension point. We are using cluster.addServiceAccount method which abstracts away how permissions are wired (but it is IRSA): https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_eks.Cluster.html#addwbrservicewbraccountid-options

I don't see this behavior changing, since in the succesor module eks-v2 alpha (which we use in our GenericClusterProviderV2) the same approach is used: https://docs.aws.amazon.com/cdk/api/v2/docs/@aws-cdk_aws-eks-v2-alpha.Cluster.html

There is a hypothetical approach to override addServiceAccount by supplying a custom cluster implementation. You will be overriding CDK constructs in this case, not the blueprints, with associated risk as this config was not tested before.

To do that you will need to create your own clusterprovider (like a subclass of GenericClusterProvider) and override internalCreateCluster method, return a subclass of eks.Cluster.

[github-actions]

This issue has been automatically marked as stale because it has been open 60 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days

[github-actions]

This issue has been automatically marked as stale because it has been open 60 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days