> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # EKS Pod Identity > EKS Pod Identity APIs with Cloud Adapter. This page describes how EKS Pod Identity maps to services in the environment where the application runs. Some profiles adapt origin API calls; others translate infrastructure or document target-native behavior. ## Supported environments | Environment | Mapping | | ------------------ | -------------------- | | Akamai | API | | Azure | API + Infrastructure | | DigitalOcean | API | | Google Cloud | API | | OCI | API | | Private Kubernetes | API | | Scaleway | API | API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on. ## How the targets compare Each row compares a capability of EKS Pod Identity with its adaptation on each target. A dash means this profile does not state the capability for that target. ### Cloud Adapter | Capability | EKS Pod Identity | Akamai, Azure, DigitalOcean, Google Cloud, OCI, Private Kubernetes, and Scaleway · Cedar | Azure · IAM | | ------------ | ---------------- | ---------------------------------------------------------------------------------------- | ----------- | | API coverage | full | high | partial | ## On Akamai, Azure, DigitalOcean, Google Cloud, OCI, Private Kubernetes, and Scaleway ### Cedar | Operation | Area | Support | Depth | Notes | | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | --------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | CreatePodIdentityAssociation / DescribePodIdentityAssociation / ListPodIdentityAssociations / UpdatePodIdentityAssociation / DeletePodIdentityAssociation | Associations | Supported | Common | Maintains the cluster, namespace and service-account binding to one AWS role. Role chaining, inline session policies and disabling session tags are unsupported. | | AssumeRoleForPodIdentity | Credentials | Supported | Common | Verifies the relaying agent and pod token, looks up the server-side association and evaluates role trust. | #### 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 Cloud Adapter deployment has its own identities and policies. Cloud Adapter deployments do not share policies or distribute policy updates to one another. Policy changes are eventually consistent within that Cloud Adapter deployment. 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 Cloud Adapter deployment 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 ### 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 Cloud Adapter deployment 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 Cloud Adapter deployment 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. ## Existing data and credentials Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application's endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target. ## Configure, tune and debug Start with [setup](/cloud-adapter/getting-started/overview) and [configuration](/cloud-adapter/configuration/overview). Use [tuning](/cloud-adapter/tuning/overview) to understand supported request tags, [debugging](/cloud-adapter/debugging/overview) to investigate a request, and [High Fidelity Cloud Emulators](/cloud-adapter/local-testing/overview) to validate a bounded reproduction.