Add EKS Pod Identity support to the module

[seifrajhi]

Is your request related to a new offering from AWS?

Is this functionality available in the AWS provider for Terraform? See CHANGELOG.md, too.

• Yes ✅: please list the AWS provider version which introduced this functionality

AWS Announced new EKS Pod Identity feature, and AWS SDK Go v2 has been released including this feature.

This New Resource was added to the AWS provider: aws_eks_pod_identity_association

This functionality has been released in v5.29.0 of the Terraform AWS Provider.

resource "aws_eks_pod_identity_association" "foo" {
  cluster_name = "my_cluster"
  namespace = "my_namespace"
  service_account_name = "foo-sa"
  iam_role_arn = "aws:......:foo"
}

Describe the solution you'd like.

The solution should allow users to specify the necessary parameters for the aws_eks_pod_identity_association resource within the Terraform module. Specifically, users should be able to define the cluster_name, namespace, service_account_name, and iam_role_arn as shown in the example below:

module "eks_pod_identity" {
  source = "path/to/eks_pod_identity_module"

  cluster_name         = "my_cluster"
  namespace            = "my_namespace"
  service_account_name = "foo-sa"
  iam_role_arn         = "aws:......:foo"
}

Describe alternatives you've considered.

I am currently using IRSA, which is ok but the new functionality is better

[FernandoMiguel]

I am currently using IRSA, which is ok but the new functionality is better honestly curious what you find it better about, @seifrajhi

other than simplifying blue/green clusters, i find it less secure, and require and extra daemonset

[seifrajhi]

Hey @FernandoMiguel ,

Honestly, I am far from giving you strong arguments to convince which is better, because it depends on the actual setup, and it differs from one environment to another. But what I can say is that one advantage of Pod Identity is that it’s much easier to understand which pod has access to a specific role in AWS—it’s as simple as calling ListPodIdentityAssociations. In contrast, IRSA requires you to:

1. Find all IAM roles that have a trust relationship with the cluster’s OIDC provider.
2. Analyze the Condition in the role trust policy on the JWT’s sub field.
3. Figure out which of your pods match this condition and are thus able to assume the role.

Another advantage is the ability to configure everything through the AWS API, without the need for any in-cluster interactions—with IRSA, you need to explicitly label service accounts with eks.amazonaws.com/role-arn. The advantages look good enough for considering this for implementation.

Also the session tagging is very interesting feature 👌

I am not defending, but it looks very promising..

You can check this document from datadaog, it gives more details

[gohmc]

The EKS Pod Identity Agent uses the hostNetwork of the node and it uses port 80

Interesting but may pose challenge to meet stringent security requirement in some environments. The way it works will not support Fargate either. Unlike IRSA, this is an EKS exclusive feature and doesn't support cluster provisioned with kOps. EKS managed addons to continue with IRSA unless change it to self-managed.

[FernandoMiguel]

@gohmc fargate does not support daemonsets anyway

[antonbabenko]

This issue has been resolved in version 20.0.0 :tada:

[ryanfaircloth]

@antonbabenko it appears you incorrectly closed this request. In this request the idea is to add support for aws_eks_pod_identity_association however the #2858 PR does not do that it instead does a different useful thing which is the new access entries feature replacing the aws_auth configmap. Can you re-open this for us as it still has merit to consider

[bryantbiggs]

what are you trying to do?

#2858 does resolve this issue - pod identity support has been added to v20 of the module

[ryanfaircloth]

In reviewing 2858 I do not see any use of "aws_eks_pod_identity_association" resources at all, the title of that PR is for access entries which replaces aws_auth. This is for aws_eks_pod_identity_association which is an alternative to IRSA style auth so we do not need to add the arn annotations to service accounts. Pods with applications using a new enough SDK version can be associated to a role now without the annotation this simplifies some use cases.

[bryantbiggs]

ah yes, you are correct. apologies, crossing all of my wires

I am still trying to figure out the best path forward for this. we could add the association to this module, but I think its better to add it on the role definition instead of the cluster definition. for adding pod identity support, I am tracking that in this WIP module that will be moved over to this org once finalized https://github.com/clowdhaus/terraform-aws-eks-pod-identity

will re-open this for now for tracking

[jacurtis]

I agree that adding an association makes more sense with the role definition than with the cluster definition.

We discussed this internally at work last week because our gut reaction was to add it to this module (or our wrapper of this module). But we decided it makes more sense to have it in our role module so that you can create the role and have the pod identity association of that role managed together.

Of course either would work, but especially as you add more and more roles it makes more sense to manage the aws_eks_pod_identity_association resource together with the aws_iam_role resource (and other supporting resources) in their own module. Therefore IMO i'd suggest to make this feature request on the terraform-aws-modules/terraform-aws-iam module.

In fact, I could see a solid justification for a pod identity role sub-module in there, similar to how the IRSA sub-module is set up. You could just combine the assumable role, the pod identity association resource, and optionally even a kubernetes_service_account resource into that sub-module.

[NeckBeardPrince]

https://github.com/terraform-aws-modules/terraform-aws-iam/pull/442

[bryantbiggs]

this is now available https://github.com/terraform-aws-modules/terraform-aws-eks-pod-identity

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.