- Coverage by target cloud
- How the targets compare
- On Google Cloud, Azure, OCI, and Private Kubernetes
- On Azure
Coverage by target cloud
How the targets compare
Each row compares a capability of EKS IRSA 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 AWS SDK sends a projected Kubernetes token to STS AssumeRoleWithWebIdentity. The broker verifies issuer, audience and service-account subject, evaluates the requested role’s trust policy, and issues a temporary AWS role session. The AWS API and session format remain those expected by the application’s SDK.Permissions and native resource access
The AssumeRoleWithWebIdentity 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 the identity services in the customer’s environment and configure the cluster issuer, token audience and role trust together. Verify a denied exchange and a denied resource action as well as successful calls. Long-running pods must renew credentials; existing sessions and later exchanges can have different outcomes after an association or policy change.On Azure
Via IAM
AWS credentials and native Azure access
With maximum adaptation, an unchanged AWS SDK calls STS AssumeRoleWithWebIdentity. The selected IAM/STS adapter validates the Kubernetes token issuer, audience, subject and role trust before issuing an AWS role session. Native Azure access uses a separate exchange: Azure federation accepts a projected Kubernetes token and issues a managed-identity token for Azure services. That token does not replace the AWS access-key session. Configure the target identity for native resource access and the configured role for the AWS API path the application uses. Keep each grant scoped to the intended service account and resources. Test a denied role assumption as well as a successful one, and verify token renewal; a successful first exchange does not prove that a long-running pod can refresh credentials.Native Azure identity
IAM Roles for Service Accounts (IRSA) lets an EKS pod exchange its Kubernetes service-account token with AWS Security Token Service (STS) for temporary IAM-role credentials. On Azure, the pod uses OpenID Connect (OIDC) federation to authenticate as a user-assigned managed identity. A federated identity credential records the AKS cluster’s issuer, the service-account subject, and the token audience. This diagram shows native Azure access. An unchanged AWS SDK uses the separate STS adapter for an AWS role session; an Azure managed-identity token is not an AWS access-key credential. The generated Terraform contains no client secret. The pod authenticates with its service-account token, so the customer does not need to store a long-lived credential for this exchange.
The three resources a grant becomes
Each IRSA grant creates three Azure resources:- A user-assigned managed identity that identifies the workload.
- A role that defines its permissions, using either a built-in Azure role or a custom role with the translated actions.
- A role assignment that grants those permissions to the identity within a resource group.
Choosing built-in or custom roles
Tensor9 translates each AWS IAM policy statement into an Azure role. The default, hybrid mode uses a built-in role only when its actions match the translated statement exactly; otherwise it creates a custom role. It does not select a built-in role that grants additional actions. Prefer-built-in selects the smallest built-in role that covers the statement, even if that role grants more permissions. Review those additional permissions before using it. Prefer-custom always creates a role with exactly the translated actions. Azure limits a tenant to around five thousand custom role definitions, so account for other deployments using the same tenant.Unsupported identities and trust
The native Azure mapping has these identity boundaries:- IAM Users and Groups have no native directory mapping. This native Azure mapping creates workload identities; it does not create directory objects for people or groups. AWS IAM objects served through the Max adapter have a separate scope.
- Role assignments bind directly to the workload identity. They do not grant permissions through group membership, where a membership change could grant access to more identities.
- AWS service-principal trust is not an Azure grant. Trust allowing EC2, Lambda, or EKS to assume a role describes a relationship with an AWS service. The AWS role trust remains part of the AWS credential path; native Azure permissions use Azure role assignments.
Limitations
△ IRSA limitations on Azure- Permission mapping is per-statement, not per-resource-per-condition. AWS IAM expresses permissions with hundreds of service-specific condition keys against individual resources. Azure RBAC binds roles over a scope hierarchy with a narrower condition model. A policy that depends on conditions without an Azure equivalent needs an explicit permission review; a successful federation exchange does not establish equivalent access.
- Custom roles draw on a finite tenant pool. Each custom role counts toward the tenant limit of roughly five thousand role definitions. Include roles used by other appliances and applications when planning capacity.
- The federated credential count per identity is capped. Azure caps how many federated credentials one managed identity may hold. The limit is enforced during compilation. If too many service accounts share one identity, split them across additional identities.
- Assignments are resource-group scoped by construction. The mapping cannot grant permissions across a subscription. Workloads that require subscription-level access need that access configured separately.
Other considerations
- Your service account keeps its role; the annotation changes. Pods keep their service accounts. Tensor9 changes workload-identity labels and the identity used for native Azure access through Kubernetes manifests. Unchanged AWS SDK calls also require the STS adapter and the role trust described in the runtime section.
- The trust path depends on the cluster’s OIDC issuer. A federated credential names the AKS cluster’s issuer URL, so workload identity is only live when the cluster was created with its OIDC issuer enabled. The appliance’s own template asserts that at apply for exactly this reason. An issuer that is quietly off produces credentials that bind to nothing and fail at the first token exchange rather than at deploy.
- Review role permissions before deployment. The plan contains either built-in role names or custom definitions with explicit actions. Compare them with the AWS policy and confirm that they grant the intended permissions before deployment.
- Naming is deterministic and derived from logical identity. Identities, role definitions and federated credentials are named from the stack’s persisted identity rather than from Terraform addresses, so the same stack compiles to the same names every time and a re-plan does not propose replacing an identity that other assignments already point at.