Skip to content

EKS Pod Identity Associations

About Pod Identity Agent Add-On

The EKS Pod Identity Add-on introduces an enhanced approach to managing IAM roles within Amazon EKS clusters, offering a simplified and efficient method for associating IAM roles with service accounts. By eliminating the need for multiple OIDC providers and complex trust policies, it addresses the challenges of the 100 OIDC provider limit per AWS account and mitigates trust policy size constraints. This add-on allows roles to trust a single service principle (pods.eks.amazonaws.com), reducing complexity, particularly in multi-cluster environments. The included identity agent, deployed as a daemonset, ensures secure and seamless integration of IAM roles with service accounts, making this add-on a recommended alternative to IRSA for managing pod identities and accessing AWS APIs within EKS clusters.

Did you know ?

EKS Pod Identity Association can be managed through various methods:

Pre-requisite

The following four (4) permissions are required to configure the Pod Identity Agent Association:

  • "eks:CreatePodIdentityAssociation"
  • "eks:DescribePodIdentityAssociation"
  • "eks:DeletePodIdentityAssociation"
  • "eks:UpdatePodIdentityAssociation"
  • "eks:ListPodIdentityAssociations"

Day-0 Support

During the Day-0 cluster creation process, select the EKS Pod Identity Agent add-on from the Managed Addons drop-down list in the Advanced section, as shown in the image below. This add-on is essential as it deploys an identity agent daemonset on each node of the cluster, along with the service account. The deployment of the identity agent must be completed before configuring the Pod Identity Association.

Service Account Status

Configuration and Deployment

Once the Identity Agent Add-on is deployed, click the Save & Customize button to add a Pod Identity Association. Add the Pod Identity Association parameters as shown in the example below:

iam:
  podIdentityAssociations:
  - createServiceAccount: true
    namespace: rafay-demo
    roleARN: arn:aws:iam::679196758854:role/demo-eks-full
    serviceAccountName: rafay-demo
  - createServiceAccount: true
    namespace: rafay-demo
    roleARN: arn:aws:iam::679196758854:role/demo-eks-full
    serviceAccountName: rafay-demo2
  - createServiceAccount: true
    namespace: rafay-demo
    permissionPolicyARNs:
    - arn:aws:iam::679196758854:policy/demo-eks-full
    serviceAccountName: rafay-demo3

Service Account Status

Once the configuration specification is updated, click Save Changes.

⚠️ Important:
The eks-pod-identity agent and the ingress-controller-v1 pod cannot run on the same cluster.

  • To use the eks-pod-identity agent, disable ingress in the custom blueprint flow, as shown below

Service Account Status

Day-2 Support

Users have the ability to add the Pod Identity Addon post-cluster creation if it was not initially included. Users can update the IAM role and tags associated with the pod identity. It is possible to delete pod associations, edit and update the Pod Identity Addon version, and remove the addon when necessary.

To add a Pod Identity Association on Day-2:

  • Select the required cluster from the Clusters page
  • Click on Access tab

Service Account Status

The Add Pod Identity page appears.

  • Provide the Namespace and Service Account
  • Toggle Create Service Account On/Off based on the requirement
  • Optionally, provide the Role ARN, Role Name, Permission Boundary ARN, Permission Policy ARNs, Tags, and the Permission Policy (IAM policy document to attach to the role)
  • Click Save

Service Account Status

Managing IRSA to Pod Identity Migration

Migrating to the EKS Pod Identity Add-On is beneficial for simplifying IAM role management within Amazon EKS clusters by consolidating the role association process and overcoming limitations related to multiple OIDC providers and trust policy size. This migration should be performed when transitioning from an existing IRSA setup to utilize the enhanced pod identity features, which streamline role associations and improve operational efficiency. Users can conduct this migration during Day-2 operations or when aiming to optimize their cluster’s IAM role management by leveraging the capabilities of the Pod Identity Add-On.

Migrating to Pod Identity

When migrating from IRSA to the Pod Identity Add-On, the following actions occur:

  • All IRSA links to service accounts are deleted (removal of annotations from service accounts)
  • Roles are updated with the necessary service principal to enable Pod Identity, and OIDC is removed from trust relationships if opted by the user
  • Pod Identity associations are created for those service accounts

Permissions Required

To ensure a smooth migration process, verify that the user or role associated with your cloud credentials has the following permissions:

  • eks:CreatePodIdentityAssociation
  • eks:DescribePodIdentityAssociation
  • eks:DeletePodIdentityAssociation
  • eks:UpdatePodIdentityAssociation
  • eks:ListPodIdentityAssociations
  • iam:UntagRole

Migrating Individual IRSA to Pod Identity

If there are multiple IRSAs (e.g., three IRSAs), and there is a need to migrate only one to the new Pod Identity mode, the process must be done manually:

  • Delete the IRSA link for the specific service account
  • Manually create the Pod Identity association for the service account

Note: The migration process will, by default, update all service accounts

Reverting to IRSA from Pod Identity

Reverting to the previous IRSA setup is a manual process: - Recreate the IRSA links for the service accounts as they were before migration - Remove the Pod Identity associations for the affected service accounts

Via RCTL

To add a Pod Identity Association via RCTL, add the podIdentityAssociation parameters to the EKS Cluster Config Spec as highlighted in the below example

kind: Cluster
metadata:
  name: demo-eks-cluster
  project: defaultproject
spec:
  blueprint: minimal
  blueprintversion: 2.9.0
  cloudprovider: demo-eks
  cniprovider: aws-cni
  proxyconfig: {}
  type: eks
---
addons:
- name: coredns
  version: v1.11.1-eksbuild.4
- name: vpc-cni
  version: v1.16.0-eksbuild.1
- name: kube-proxy
  version: v1.29.0-eksbuild.1
- name: aws-ebs-csi-driver
  version: latest
- name: eks-pod-identity-agent
  version: latest
apiVersion: rafay.io/v1alpha5
iam:
  podIdentityAssociations:
  - createServiceAccount: true
    namespace: rafay-demo
    roleARN: arn:aws:iam::679196758854:role/demo-eks-full
    serviceAccountName: rafay-demo
  - createServiceAccount: true
    namespace: rafay-demo
    roleARN: arn:aws:iam::679196758854:role/demo-eks-full
    serviceAccountName: rafay-demo2
  - createServiceAccount: true
    namespace: rafay-demo
    permissionPolicyARNs:
    - arn:aws:iam::679196758854:policy/demo-eks-full
    serviceAccountName: rafay-demo3
  serviceAccounts:
  - attachRoleARN: arn:aws:iam::679196758854:role/eksctl-demo-imported-clus46-addon-vpc-cni-Role1-badgX6yB68vw
    metadata:
      name: demo-test
      namespace: rafay-demo
  withOIDC: true
kind: ClusterConfig
managedNodeGroups:
- amiFamily: AmazonLinux2
  desiredCapacity: 2
  iam:
    withAddonPolicies:
      autoScaler: true
  instanceTypes:
  - t3.xlarge
  maxSize: 2
  minSize: 0
  name: ng-51ada954
  version: "1.29"
  volumeSize: 80
  volumeType: gp3
metadata:
  name: demo-eks-cluster
  region: us-west-2
  tags:
    email: demo@rafay.co
    env: dev
  version: "1.29"
vpc:
  cidr: 192.168.0.0/16
  clusterEndpoints:
    privateAccess: true
    publicAccess: false
  nat:
    gateway: Single

Migration from IRSA to PIA Via RCTL

Use the following command to migrate the cluster to pod identity and remove the OIDC provider, which will disable the existing OIDC provider and transition the cluster to use pod identity instead:

rctl migrate-to-pod-identity <cluster-name> --remove-oidc-provider=true

Post-Migration Steps

For Terraform Users

For Terraform users, this will result in a difference between the cluster configuration in the resource file and the cloud object with respect to pod identity associations and IRSA, due to creation and deletion during the migration step.

To resolve: - Execute the following command to sync the state file:

terraform apply --refresh-only
  • Run the following command to output the resource file, which will now align with the new state file:
terraform show
  • Update the resource file:
    • Add the newly created pod identities
    • Remove the IRSA entries to avoid further discrepancies in the state files

For git/rctl Users

For Git/rctl users, the source file will be missing changes related to pod identity associations and IRSA, due to creation and deletion during the migration step.

To resolve: - Manually update the pod identity section to align with the current cluster configuration - Manually delete the IRSA section