Add support for Cross Account Pod Identity Associations

[naclonts]

Description

Add support for setting up cross-account resource access with pod identity.

Specifically, eksctl now accepts targetRoleARN and disableSessionTags parameters when creating or updating Pod Identity Associations.

Manual testing

Tested with a few different scenarios:

- 1. Using existing role in source account -

Set up the roles and policies in the cross-account pod identity blog post.

Then create the cluster with eksctl:

# Use the example template from eksctl docs. Adjust clusterName, region, and account IDs.
% cat << EOF > cluster.yaml 
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
  region: us-west-2
  version: "1.32"

addons:
  - name: vpc-cni
  - name: coredns
  - name: kube-proxy
  - name: eks-pod-identity-agent

iam:
  podIdentityAssociations:
  - namespace: default
    serviceAccountName: demo-app-sa
    createServiceAccount: true
    roleARN: arn:aws:iam::111122223333:role/account-a-role
    targetRoleARN: arn:aws:iam::444455556666:role/account-b-role
    disableSessionTags: false

managedNodeGroups:
  - name: my-cluster
    instanceType: m6a.large
    privateNetworking: true
    minSize: 2
    desiredCapacity: 2
    maxSize: 3
EOF

# Create the cluster
% ./eksctl create cluster -f cluster.yaml

And check access:

% kubectl run awscli \
  --image=amazon/aws-cli:latest \
  --restart=Never \
  --command \
  --overrides='{ "spec": { "serviceAccountName": "demo-app-sa" }}' \
  -- sleep infinity

% kubectl exec awscli -- /bin/bash -c "aws sts get-caller-identity"
{
    "UserId": "...",
    "Account": "444455556666",
    "Arn": "arn:aws:sts::444455556666:assumed-role/account-b-role/my-cluster..."
}

---

- 2. Creating a new role in source account based on permissionPolicyARNs -

Instead of creating the EKS account's role ahead of time, eksctl can create it based on passed-in permissionPolicyARNs, wellKnownPolicies, and permissionsBoundaryARNs. This follows the existing pattern for pod identity creation with eksctl.

Example:

# Note the modified iam.podIdentityAssociations fields
% cat << EOF > cluster.yaml 
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: xacct-pod-id-3
  region: us-west-2
  version: "1.32"

addons:
  - name: vpc-cni
  - name: coredns
  - name: kube-proxy
  - name: eks-pod-identity-agent

iam:
  podIdentityAssociations:
  - namespace: default
    serviceAccountName: demo-app-sa
    createServiceAccount: true

    # This policy must allow assumeRole access to account-b-role
    permissionPolicyARNs: ["arn:aws:iam::111122223333:policy/eks-pod-identity-xacct-policy"]
    wellKnownPolicies:
      externalDNS: true
    targetRoleARN: arn:aws:iam::444455556666:role/account-b-role

managedNodeGroups:
  - name: xacct-pod-id-2-mng
    instanceType: m6a.large
    privateNetworking: true
    minSize: 2
    desiredCapacity: 2
    maxSize: 5
EOF

# Create the cluster
% ./eksctl create cluster -f cluster.yaml

In account B, ensure the role created above is in the Trust Relationships for account-b-role.

And check access:

% kubectl run awscli \
  --image=amazon/aws-cli:latest \
  --restart=Never \
  --command \
  --overrides='{ "spec": { "serviceAccountName": "demo-app-sa" }}' \
  -- sleep infinity

% kubectl exec awscli -- /bin/bash -c "aws sts get-caller-identity"
{
    "UserId": "...",
    "Account": "444455556666",
    "Arn": "arn:aws:sts::444455556666:assumed-role/account-b-role/my-cluster..."
}

---

- 3. Create with CLI -

% ./eksctl create podidentityassociation --cluster my-cluster \
  --namespace default \
  --service-account-name demo-app-sa \
  --role-name xacct-pod-id-4c  \
  --target-role-arn arn:aws:iam::444455556666:role/account-b-role
  --permission-policy-arns arn:aws:iam::111122223333:policy/eks-pod-identity-xacct-policy

In account B, ensure the role created above is in the Trust Relationships for account-b-role.

% kubectl run awscli \
  --image=amazon/aws-cli:latest \
  --restart=Never \
  --command \
  --overrides='{ "spec": { "serviceAccountName": "demo-app-sa" }}' \
  -- sleep infinity

% kubectl exec awscli -- /bin/bash -c "aws sts get-caller-identity"
{
    "UserId": "...",
    "Account": "444455556666",
    "Arn": "arn:aws:sts::444455556666:assumed-role/account-b-role/my-cluster..."
}

- 4. Update existing Pod Identity Association -

After creating the above, update the disableSessionTags param:

% ./eksctl update podidentityassociation --cluster my-cluster \
  --namespace default \
  --service-account-name demo-app-sa \
  --role-arn arn:aws:iam::111122223333:role/account-a-role \
  --disable-session-tags
# ...
2025-07-14 18:43:29 [ℹ]  all tasks were completed successfully

%  aws eks describe-pod-identity-association --cluster my-cluster --association-id a-xxxxxx
{
    "association": {
        # ...
        "disableSessionTags": true,
        "targetRoleArn": "arn:aws:iam::444455556666:role/account-b-role",
        # ...
    }
}

The disableSessionTags value does not change to false if the flag isn't provided

% ./eksctl update podidentityassociation --cluster my-cluster \
  --namespace default \
  --service-account-name demo-app-sa \
  --role-arn arn:aws:iam::111122223333:role/account-a-role

%  aws eks describe-pod-identity-association --cluster my-cluster --association-id a-xxxxxx
{
    "association": {
        # ...
        "disableSessionTags": true,   # still true
        "targetRoleArn": "arn:aws:iam::444455556666:role/account-b-role", # still unchanged
        # ...
    }
}

Passing no-disable-session-tags will set it to false:

% ./eksctl update podidentityassociation --cluster my-cluster \
  --namespace default \
  --service-account-name demo-app-sa \
  --role-arn arn:aws:iam::111122223333:role/account-a-role \
  --no-disable-session-tags

%  aws eks describe-pod-identity-association --cluster my-cluster --association-id a-xxxxxx
{
    "association": {
        # ...
        "disableSessionTags": false,
        "targetRoleArn": "arn:aws:iam::444455556666:role/account-b-role",
        # ...
    }
}

Checklist

• Added tests that cover your change (if possible)
• Added/modified documentation as required (such as the README.md, or the userdocs directory)
• Manually tested
• Made sure the title of the PR is a good description that can go into the release notes
• (Core team) Added labels for change area (e.g. area/nodegroup) and kind (e.g. kind/improvement)

BONUS POINTS checklist: complete for good vibes and maybe prizes?! 🤯

• Backfilled missing tests for code in same general area 🎉
• Refactored something and made the world a better place 🌟