Skip to main content
On this page

​
Coverage by target cloud

​
How the targets compare

Each row compares a capability of EKS Pod Identity with its adaptation on each target. A dash means this row is not stated for that target.

​
Max adaptation

​
Infrastructure-only adaptation

​
On Google Cloud, Azure, OCI, and Private Kubernetes

​
Via Cedar

​
AWS credential exchange

The EKS association records a role for a cluster, namespace and service account. The EKS Auth broker verifies the relaying agent and projected pod token, looks up that association and evaluates role trust before issuing a temporary AWS session. The caller cannot choose an arbitrary role in the credential request.

​
Permissions and native resource access

The AssumeRoleForPodIdentity response supplies a temporary AWS role session. With enforcement enabled, receiving adapters authorize AWS API requests against the role’s supported IAM permissions using Cedar, the policy engine underpinning the adapter’s authorization decisions. The adapter handles the AWS credential exchange; Cedar evaluates the supported permissions. Native cloud APIs use separate provider credentials and grants; Kubernetes RBAC governs access to the cluster API. Each appliance has its own identities and policies. Appliances do not share policies or distribute policy updates to one another. Policy changes are eventually consistent within that appliance. New grants may not be usable immediately, and revoked permissions may remain effective until the change propagates. Verify the dependent operation before relying on a policy change; a successful update alone does not prove propagation.

​
Deployment and renewal

Deploy association management, the EKS Auth broker and the cluster’s credential agent together. Register the broker’s backend role, authorize the agent to request credentials for the cluster, and configure an HTTPS broker address the agent can resolve and reach. The broker must be able to verify the cluster’s token issuer and signing keys. Configure admission to project a pod-bound token for audience pods.eks.amazonaws.com and select the AWS container credential provider. Check for other credentials that would take precedence. Verify the intended role in a newly admitted pod, a denied exchange and a denied resource action. Long-running pods must renew credentials; existing sessions and later exchanges can have different outcomes after an association or policy change.

​
Association and trust limits

Associations use one role in the cluster’s appliance account. Role chaining, inline session policies and disabling session tags are unsupported. Omit targetRoleArn, policy and disableSessionTags from create and update requests, including an explicit false for disableSessionTags. The role must trust pods.eks.amazonaws.com for both sts:AssumeRole and sts:TagSession. The broker derives the Kubernetes session tags from the verified pod. Supported trust conditions use StringEquals or StringLike on the six derived aws:RequestTag keys; other trust conditions are refused.

​
On Azure

​
Via IAM

​
Association management and AWS credential exchange

Maximum adaptation retains the EKS association API and the EKS Auth credential exchange as separate services. The association records which role belongs to a cluster, namespace and service account. For AssumeRoleForPodIdentity, the broker verifies the relaying agent and the pod’s projected token, looks up that server-side association and evaluates the role’s current trust policy. The caller does not choose an arbitrary role in the exchange request. The result for an unchanged AWS SDK is an AWS role session. Azure workload-identity federation is a separate native access mechanism that produces Azure tokens; it does not replace the AWS session format. Verify the pod token issuer and audience, the association and role trust, and any Azure identity needed to access target resources. Changing an association affects subsequent exchanges; already issued sessions retain their own expiration. Associations use one role in the cluster’s appliance account. Role chaining, inline session policies and disabling session tags are unsupported. Omit targetRoleArn, policy and disableSessionTags from create and update requests, including an explicit false for disableSessionTags. The role must trust pods.eks.amazonaws.com for both sts:AssumeRole and sts:TagSession. The broker derives the Kubernetes session tags from the verified pod. Supported trust conditions use StringEquals or StringLike on the six derived aws:RequestTag keys; other trust conditions are refused. Deploy association management, the EKS Auth broker and the cluster’s credential agent together. Register the broker’s backend role, authorize the agent to request credentials for the cluster, and configure an HTTPS broker address the agent can resolve and reach. The broker must be able to verify the cluster’s token issuer and signing keys. Configure admission to project a pod-bound token for audience pods.eks.amazonaws.com and select the AWS container credential provider. Check for other credentials that would take precedence. Verify the intended role in a newly admitted pod, a denied exchange and a denied resource action. Long-running pods must renew credentials; existing sessions and later exchanges can have different outcomes after an association or policy change.

​
Native Azure identity

EKS Pod Identity associates a Kubernetes service account with an IAM role. An agent in the cluster gives the pod temporary credentials, without an OpenID Connect (OIDC) provider. Azure uses OIDC federation. The pod authenticates with its service-account token as a user-assigned managed identity. A federated identity credential records the AKS cluster’s issuer and the service account that may use that identity. This diagram shows the native Azure binding. Maximum adaptation separately retains EKS association management and EKS Auth credential exchange for AWS SDK calls. The pod still receives permissions without a stored client secret, but the AKS cluster must have its OIDC issuer enabled. Deployments moving from Pod Identity need to configure this additional dependency.
Before: on AWS an EKS Pod Identity association binds a service account to an IAM role and an on-cluster agent hands credentials to the pod, with no OIDC provider involved. Native Azure access: the pod token issued by AKS authenticates a managed identity through a federated credential. The separate EKS association and EKS Auth adapter path is described in the AWS credential exchange section.Before: on AWS an EKS Pod Identity association binds a service account to an IAM role and an on-cluster agent hands credentials to the pod, with no OIDC provider involved. Native Azure access: the pod token issued by AKS authenticates a managed identity through a federated credential. The separate EKS association and EKS Auth adapter path is described in the AWS credential exchange section.

​
What the association becomes

One Pod Identity association becomes a user-assigned managed identity, a role (a built-in Azure role when the catalogue covers the policy statement exactly, a custom role definition otherwise), a role assignment scoped to the resource group, and a federated identity credential naming the cluster’s issuer and your service account. For native Azure access, the federated credential provides the binding. Its issuer, subject, and audience identify which service account and namespace may authenticate as the managed identity. All federated credentials for one identity are generated together. Tensor9 checks Azure’s per-identity credential limit during compilation and stops the build if it is exceeded. If many service accounts share an identity, divide them across additional identities to stay within the limit.

​
Limitations

△ Pod Identity limitations on Azure
  • An OIDC issuer is required. Azure workload identity requires the AKS cluster’s OIDC issuer to be enabled. EKS Pod Identity does not require an OIDC provider, so this adds a deployment requirement.
  • Association state and Azure federation are separate. EKS tooling uses the association adapter. Native Azure access uses federated credentials on managed identities. Review both bindings; an Azure credential alone does not create an EKS association or issue an AWS role session.
  • Limit how many service accounts share an identity. Azure caps federated credentials per managed identity, and the cap is enforced at compile time. Split service accounts across additional identities if their credential count exceeds the limit.
  • IAM Users and Groups have no native directory mapping. The native Azure mapping creates workload identities, not directory objects for people or groups. Configure native grants to people in Azure’s directory separately. AWS IAM objects served through the Max adapter have a separate scope.
  • Some permission conditions cannot be preserved. AWS IAM statements become Azure RBAC roles over a scope hierarchy with a narrower condition model. Review effective access where a source IAM condition has no Azure equivalent.

​
Other considerations

  • Enable the cluster’s OIDC issuer before deployment. Without the issuer, federated credentials can be created but the first token exchange fails. The appliance template checks that the issuer is enabled when the stack is applied.
  • Workload-identity changes are in the manifests. Pods keep their service accounts. Configure Azure workload-identity labels for native Azure access and the agent, association and credential route for unchanged AWS SDK calls. These paths produce different credentials and require separate validation.
  • Read the emitted roles before cutover. The plan contains either built-in role names or custom definitions with explicit actions. Compare those actions with the original IAM policy before deployment, particularly where broader Azure scopes could grant additional access.
Service Catalog.