Supported environments
- Akamai
- Azure
- DigitalOcean
- Google Cloud
- OCI
- Private Kubernetes
- Scaleway
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
On Akamai, Azure, DigitalOcean, Google Cloud, OCI, Private Kubernetes, and Scaleway
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 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 audiencepods.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. OmittargetRoleArn, 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. OmittargetRoleArn, 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.
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 service 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.
Service level agreements
Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider’s own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the SLA tables, measurement rules, and scaling conditions.EKS Pod Identity to IAM
SLA status: Not applicable This mapping provisions native target-cloud permissions. Application authorization uses the target cloud’s identity system; requests do not pass through an IAM service adapter. The IAM-to-Cedar adapter has separate service levels.EKS Pod Identity to Cedar
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Cluster, workload and identity calls validate AWS-shaped intent, record the desired resource and reconcile native objects on tensor9::1.0.0::iam::cedar+opal. In-cluster Kubernetes traffic and application packet flow are not proxied by this control-plane estimate. Provider provisioning and image pull time are readiness phases; adapter validation, durable admission and status conversion remain covered.How the latency targets were chosen
Workload identity binding: 10 ms monthly p99.AssumeRoleForPodIdentity, CreatePodIdentityAssociation, DeletePodIdentityAssociation, DescribePodIdentityAssociation, ListPodIdentityAssociations, UpdatePodIdentityAssociation. Bounded identity validation, authorization and durable binding mutation.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Independent clusters, services, tasks and identity associations reconcile concurrently. Mutations for one object serialize by generation, list calls are bounded pages, and status polling must not starve writes. Qualification fixes object count, manifest size, container count, tag count and concurrent reconcilers. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
Accepted desired state is durable and generation ordered. Workload identity binds only the intended service account/role, secrets are not emitted into public fields, and observed status never claims readiness before the target reports it. Unsupported scheduling or networking modes fail before partial creation.Example and diagnosis
CreateCluster records a bounded cluster specification and returns its stable identity. Native provisioning may continue after the adapter response. DescribeCluster is a bounded read of desired plus observed state and must not report ACTIVE until the target control plane is actually ready. Usetensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Install and run
The documentation and SLAs are public. Downloading and running the Cloud Adapter binary requires an entitled customer account. SetT9_API_KEY as described in Install and Authenticate, then list the adapters your account may use with this origin: