- Coverage by target cloud
- How the targets compare
- On Google Cloud, Azure, OCI, and Private Kubernetes
- On Azure
- Service level agreements
- Debug this service
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.
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 IRSA 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 IRSA 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.AssumeRoleWithWebIdentity, GetCallerIdentity. 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.