- Coverage by target cloud
- How the targets compare
- On Google Cloud, Azure, OCI, and Private Kubernetes
- On Google Cloud
- On Azure
- On OCI
- Service level agreements
- Debug this service
Coverage by target cloud
How the targets compare
Each row compares a capability of IAM 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
Max IAM and STS
Max adaptation serves AWS IAM and Security Token Service (STS) requests within each appliance. The adapter supports 50 IAM administration operations across roles, customer-managed policies, instance profiles and OIDC providers, plusGetCallerIdentity, AssumeRole and AssumeRoleWithWebIdentity. Applications keep the supported AWS request formats.
Each appliance has its own identities, policies and authorization state. Appliances do not share policies or distribute policy updates to one another. Policy updates reach only the relevant replicas within the same appliance; changing permissions in one appliance does not change permissions in another.
Account IDs in adapted resource ARNs identify logical accounts within the appliance. These account records do not create cloud-provider accounts or billing relationships and do not provide AWS Organizations governance.
Cedar is the policy engine underpinning the adapter’s authorization decisions. Tensor9’s adapter handles IAM administration, STS credential exchanges and the translation of supported IAM policies into Cedar rules. Cedar evaluates those rules for requests handled by receiving adapters. Role trust is evaluated separately when a session is created.
Native permission translation is a different choice: it converts declared permissions into the target cloud’s grants during provisioning and does not itself serve AWS IAM administration calls.
This page is about the IAM in your application’s stack. The permissions your control plane needs inside a customer’s environment are a separate subject with its own model; see Permissions Model and Cross-Cloud IAM.
IAM edits, STS trust checks and downstream authorization are separate steps.
Access keys and secret keys
Max adaptation supports access keys and secret keys on Google Cloud, Azure, OCI and Private Kubernetes. Use the appliance-issued pair supplied by your appliance administrator with your AWS SDK or CLI. ConfigureAWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, the appliance endpoint and its signing region. Supported service requests use AWS Signature Version 4 (SigV4); the receiving adapter verifies the signature and resolves the configured credential’s account.
This long-term pair identifies a logical account root within the appliance, not an IAM user or a cloud-provider account. Keep the secret when it is issued; it is shown once. It is not valid at AWS endpoints or in another appliance. Native permission translation does not issue this runtime credential.
A long-term pair has no session token. Temporary credentials from the supported STS operations identify a role session and also require AWS_SESSION_TOKEN; they expire. Credential use does not provide IAM user access-key administration: CreateAccessKey, ListAccessKeys, UpdateAccessKey and DeleteAccessKey are unsupported. The combined IAM and STS management endpoint has the separate protected-access boundary described below.
Authentication and management access
Temporary credentials identify a verified role session. Receiving adapters verify the request signature, session validity and account before using that identity for authorization.GetCallerIdentity returns the account, ARN and user ID; an assumed-role session has an assumed-role ARN, not simply its role’s IAM ARN.
Protect the combined IAM and STS management endpoint with authenticated deployment access. Requests without issued session credentials use its configured bootstrap caller; this endpoint is not a general lookup of arbitrary AWS access keys. The separate public web-identity route accepts only AssumeRoleWithWebIdentity and verifies the token before issuing credentials.
Configure authorization enforcement on receiving adapters. In enforce mode, a denied decision stops the operation and returns the receiving service’s error. Report-only mode records would-be denials without blocking requests. Policy propagation does not turn report-only mode into enforcement.
Policy authoring and runtime changes
Keep authoring supported policies in IAM JSON. Declared stack policies and runtime IAM operations are separate ways to supply them. IAM reads return stored role, policy and relationship records, not documents reconstructed from compiled Cedar rules. Runtime policy edits are validated before acceptance. Accepted changes update IAM records and propagate to the policy state used for authorization. Recording a change and observing its effect on a later request are not the same event. Creating a non-default managed-policy version does not change effective permissions. Making it the default changes the version used by attached roles. Inline policies and policy attachments also affect permissions. Role-trust changes instead govern future session creation; they are evaluated separately from Cedar identity policies. IAMAllow statements translate to Cedar permit rules and Deny statements to forbid rules. Supported actions, resource ARNs and conditions determine their scope. On the Cedar authorization path, unsupported restrictions are refused rather than silently dropped. Role trust remains a separate IAM-policy evaluation.
Eventual consistency for policy changes
IAM policy changes are eventually consistent, as in AWS IAM. Policy consistency is not customer-configurable. Changes take time to reach reads and authorization checks, including updates made through another replica in the same appliance. A successful IAM response does not guarantee that subsequent reads or authorization checks already reflect the change. New grants may not be usable immediately, and revoked permissions may remain effective until the change propagates. With enforcement enabled, a request is blocked when the policies used for that check deny it; those policies can still be older than the latest accepted edit. Work already authorized can continue. Other appliances keep their own policies. An error or timeout after commit does not imply rollback. The change may have committed even though the caller did not receive success; do not treat a failed response as proof that the old permissions remain in effect.
Success can precede propagation. A dependent-operation check is not a freshness guarantee for every replica.
Propagation and dependent workflows
Verify propagation before starting a workflow that depends on the change; a fixed sleep is not proof that propagation has completed. Check the relevant IAM state and the allowed or denied result needed by that workflow. One observed result does not prove that every replica is up to date or that the next request will observe the same policy state. Avoid putting IAM changes in a critical request path that assumes immediate visibility. There is no fixed propagation deadline. An unavailable replica or policy service can delay visibility or make requests fail. Eventual consistency does not guarantee offline availability, and there is no universal rule that permissions become denied after a fixed cache age. Test propagation, failure and recovery across the appliance’s replicas with the required enforcement settings.Authorization decisions
Cedar evaluates the principal, action, resource and supported request context against the selected policies. Any matchingforbid overrides a permit. With no matching permit, the decision is deny. Policy order does not change that decision.
These rules describe supported identity-policy authorization. IAM management also has a privileged account-root path, and STS uses separate trust checks. They do not imply that every AWS policy layer or every receiving service is covered.
Explicit deny overrides allow; without a matching allow, the decision is deny.
Supported conditions
Identity policies supportaws:CurrentTime, aws:EpochTime, and three Route 53 change keys: route53:ChangeResourceRecordSetsNormalizedRecordNames, route53:ChangeResourceRecordSetsRecordTypes and route53:ChangeResourceRecordSetsActions. The DNS subset includes supported set, wildcard, negation and existence tests. Accepted operators depend on the key.
aws:SourceIp, aws:PrincipalTag, aws:SecureTransport and MFA identity-policy keys are unsupported. A value being available in the deployment does not itself make its condition supported. Stored role tags do not imply general tag-based authorization.
Role-trust conditions are separate. OIDC trust supports issuer-qualified audience and subject comparisons using StringEquals and StringLike. Pod Identity trust supports those operators on its six verified request-tag keys. Neither capability adds general identity-policy condition coverage.
Role trust and temporary credentials
AssumeRole evaluates role trust before creating an expiring session. Conditional cross-account assumption is supported between accounts served by the same appliance when caller-side authorization and target-role trust both permit it. This does not provide cross-appliance trust or policy sharing. Account-root delegation and assumption into arbitrary real AWS accounts are outside this scope.
AssumeRoleWithWebIdentity verifies the token signature, issuer, audience, subject and expiry against a registered OIDC provider and evaluates role trust. The dedicated Pod Identity exchange verifies the agent and pod token, selects the role from its association and issues a session with attested tags. These are real credential exchanges, not static credentials derived from a role name.
Configured replicas within one appliance can share session verification. This does not make credentials valid in another appliance. Sessions expire and are tied to the role’s identity, so deleting and recreating a role with the same name does not revive its old sessions. Trust changes govern future assumptions; permission changes affect later authorization checks as they propagate. Neither effect is guaranteed to be visible immediately after a successful IAM response.
Normal AssumeRole does not support role chaining, session policies, arbitrary session tags, ExternalId, MFA, SourceIdentity or ProvidedContexts. The trusted Pod Identity tag path is separate. Neither session issuance nor GetCallerIdentity calls AWS STS, but OIDC discovery and signing-key retrieval may require access to the configured issuer.
Administration and simulation scope
Administration includes role updates and tags; customer-managed policy creation, versions and tags; inline role policies and attachments; instance-profile lifecycle, membership and tags; and OIDC-provider lifecycle, audiences, thumbprints and tags. Policy versioning supports up to five versions per policy. AWS-managed policy documents are not supplied by the runtime catalog; use supported customer-managed policies. The IAM administration endpoint does not implementSimulatePrincipalPolicy or SimulateCustomPolicy. A separate workload-identity endpoint supports restricted principal simulation when configured with a policy evaluator. That simulation uses its configured workload and explicit actions and resource ARNs; it does not accept arbitrary principals or ad-hoc policy documents. A simulated deny may differ from the allowed response in report-only mode.
User, group and access-key administration, SAML federation, service-linked roles, Access Analyzer, credential reports and Access Advisor are outside the implemented API scope.
Diagnostics and deployment
Authorization diagnostics record denials and would-be denials, including the principal, action, resource, result, enforcement mode and readiness. They do not record every successful permit or identify the matched policy statements. Policy validation and offline evaluation help test examples; they are not an Access Analyzer equivalent. The IAM and STS endpoints and Cedar evaluation run within each appliance. There is no shared policy distribution mechanism between appliances. Use the target and deployment configuration supported for that environment; portable policy evaluation does not imply identical native identity provisioning on every cloud. AWS adapter permissions and the target cloud’s native grants remain separate. Tensor9 operates the adapter and policy propagation within each appliance. Diagnostic destinations and retention follow the appliance’s logging configuration. Before cutover, test administration, denied requests, credential renewal, permission-change propagation and outages across that appliance’s replicas. A healthy replica count does not prove that a particular policy change has reached every authorization check.Limitations
△ Limitations- The policy language is a supported subset. Identity-policy NotAction, NotResource and NotPrincipal are refused, as are policy variables, question-mark wildcards and unsupported principal forms. Action wildcards are limited to * or service:*; resource patterns support broader star matching. Resolve unsupported restrictions before using the Cedar authorization path.
- Permissions boundaries are not enforced by local Cedar. Role creation rejects a boundary unless explicitly acknowledged. Acknowledgment retains the attribute but does not enforce it; omitting this restriction can broaden permissions. Native AWS enforcement is a separate domain.
- Resource-policy support belongs to the receiving service. Do not assume that translating an identity policy also supplies resource-policy APIs or AWS resource/identity-policy combination rules.
- Organizations SCPs are not enforced by this authorizer. Account and organization restrictions are not added by successful IAM administration or token exchange.
- Propagation and enforcement are separate. New permissions can take time to become usable, and revoked permissions can remain effective during propagation. Report-only mode does not block denied requests even after the updated policy is visible.
- Each appliance is independent. Policies, policy updates and authorization state are not shared between appliances. Replica-shared credentials are confined to the same appliance and do not grant global AWS authority.
On Google Cloud
Via IAM
Infrastructure only: native permissions
Tensor9 translates the roles, policies, and attachments declared by your stack into Google Cloud IAM grants during provisioning. Google Cloud IAM binds predefined or custom roles to principals. Tensor9 maps supported AWS actions to permissions; the generated scope and supported condition mapping can differ. The resulting grants use predefined or custom role permissions and resource scopes.Permission differences
AWS policies can restrict individual resources and request conditions. This mapping does not preserve every restriction. Mappings that broaden access require explicit acceptance; incompatible restrictions stop translation. Some mappings grant fewer permissions. Review generated actions and scopes before deployment. The Cedar-based adapter separately serves supported AWS IAM calls and evaluates supported AWS identity policies.Application and identity changes
This mapping provisions grants; it does not serve runtime AWS IAM calls such asiam:CreateRole or iam:AttachRolePolicy. Replace references to AWS role ARNs in trust policies, assume-role calls, and resource policies with the appropriate Google identity. New target grants are created during deployment; AWS policy objects are not copied.
On Azure
Via IAM
Infrastructure only: native permissions
Tensor9 translates the roles, policies, and attachments declared by your stack into Azure RBAC and Entra grants during provisioning. Azure RBAC assigns built-in or custom roles over a scope hierarchy. Tensor9 maps supported actions and uses target assignment scopes; not every AWS resource or condition restriction is preserved. The resulting grants use role-assignment granularity.Permission differences
AWS policies can restrict individual resources and request conditions. This mapping does not preserve every restriction. Mappings that broaden access require explicit acceptance; incompatible restrictions stop translation. Some mappings grant fewer permissions. Review generated actions and scopes before deployment. The Cedar-based adapter separately serves supported AWS IAM calls and evaluates supported AWS identity policies.Application and identity changes
This mapping provisions grants; it does not serve runtime AWS IAM calls such asiam:CreateRole or iam:AttachRolePolicy. Replace references to AWS role ARNs in trust policies, assume-role calls, and resource policies with the appropriate Azure identity. New target grants are created during deployment; AWS policy objects are not copied.
On OCI
Via OCI IAM
Infrastructure only: native permissions
Tensor9 translates the roles, policies, and attachments declared by your stack into OCI IAM grants during provisioning. OCI IAM uses policy statements scoped to compartments and groups. This mapping uses OCI verbs and resource families, which can group AWS actions or resources differently. The resulting grants use group and compartment granularity.Permission differences
AWS policies can restrict individual resources and request conditions. This mapping does not preserve every restriction. Mappings that broaden access require explicit acceptance; incompatible restrictions stop translation. Some mappings grant fewer permissions. Review generated actions and scopes before deployment. The Cedar-based adapter separately serves supported AWS IAM calls and evaluates supported AWS identity policies.Application and identity changes
This mapping provisions grants; it does not serve runtime AWS IAM calls such asiam:CreateRole or iam:AttachRolePolicy. Replace references to AWS role ARNs in trust policies, assume-role calls, and resource policies with the appropriate OCI identity. New target grants are created during deployment; AWS policy objects are not copied.
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.IAM to Cedar
What Tensor9 covers. The SLA covers permission checks, deciding whether to accept a request, time waiting inside the adapter, request handling, coordination, retries, internal storage and response handling. Waiting for the target service is excluded only when that wait is measured separately and the agreement allows the exclusion. Your agreement must name the covered deployment, operations, request limits and traffic limits. Unlisted operations are not automatically covered. Incorrect results are still bugs even when the availability target is met.
Scaling limits. Tensor9 automatically adds adapter capacity within the traffic growth, burst size and infrastructure limits in your agreement. The standard service level does not promise a fixed request rate or unlimited scaling. Capacity depends on request sizes and types, how traffic is distributed across keys or message groups, target configuration and spare capacity for failures. More adapter processes cannot speed up every shared or sequential step. You remain responsible for target-service capacity; failures caused independently by the provider are outside this SLA.
Read the details. Each linked service page lists the covered operations, request limits, measurement rules, data guarantees, scaling limits and examples. This summary does not add coverage beyond those terms. Your signed agreement determines the service levels that apply to your deployment.
Adapter and scope
These standard terms cover supported AWS IAM administration, supported AWS STS operations, and embedded authorization using Cedar. Each is measured separately, even when the same application uses all three.
Cedar is Tensor9’s authorization mechanism, not an independently operated target cloud whose execution can be excluded. Policy lookup, context construction, Cedar evaluation and enforcement are adapter work.
Your signed agreement determines which components enforce permissions, the deployment requirements, and the policy complexity and traffic levels covered.
Latency targets
Any stricter limits of the individual APIs still apply. The table’s size limits define which requests receive a latency target; they do not increase IAM’s allowed request sizes. Larger supported responses have no latency target under these standard terms and must not be truncated to qualify. Counting policies and entities does not tell you how long permission checks take. The agreed workload must also describe the complexity of conditions, policy matching, request context, and the mix of allowed and denied requests. Testing an empty policy set that always allows access does not represent that workload.Covered IAM operations
The administration service level includes exactly these 50 operations. Each operation retains its own measurement even when several share a row and the administration latency budget.
The list-operation limit applies to one response page, not an SDK paginator reading all pages. Availability covers these operations with the request options supported by the adapter, rather than only requests within the latency payload bounds.
The separate STS set contains exactly
GetCallerIdentity, AssumeRole and AssumeRoleWithWebIdentity. Those names refer to STS operations, not additional IAM operations. Unsupported session-policy or MFA forms do not acquire a guarantee from inclusion of the operation name.
Embedded enforcement is not another IAM API
The permission-check latency target applies while the adapter handles a supported application request. The agreement must name the components enforcing permissions and the application operations whose permission checks are measured. This is part of request handling, not a separate API call or another name forSimulatePrincipalPolicy.
SimulatePrincipalPolicy is not covered by these standard terms. Its separately described partial support does not substitute for a real enforcement guarantee. A check that only reports a decision without enforcing it does not meet this requirement.
An S3 request can have an SLA for the object operation and another for its permission check. Time spent checking permissions can count toward both targets, but is counted only once in the request’s total elapsed time.
What counts as available
Correctly denying a request under the policy counts as a successful permission check. An availability SLA does not promise that every caller receives access. If the adapter cannot load usable policy data, it must refuse the request to prevent unsafe access. That is still an adapter availability failure. It must not be counted as a normal policy denial just because both cases refuse access. Similarly, a successful policy update does not prove every permission-checking component has received it. Saving a policy, checking permissions, and distributing policy updates are measured separately.Timing and external waits
Depending on the operation, adapter latency includes loading policies, preparing request context, checking signatures and identity claims, checking trust rules, issuing credentials, using local caches, and retrying. Accessing the adapter’s policy store also counts, even when it uses a managed database. For STS, time spent waiting for an external identity provider or retrieving external keys can be excluded only when separately measured and allowed by the agreement. Local cache work and local retry delays still count toward adapter latency. Cedar evaluation always counts toward adapter latency.Security, policy durability and consistency
The adapter must:- Allow access only when the supported IAM-to-Cedar policy rules permit it.
- Preserve explicit-deny precedence, deny access by default, and respect role and session restrictions and expiration.
- Reject unsupported restrictions rather than silently ignoring them.
- Save covered policy changes durably in the policy store before returning success.
- Install a complete, verified policy snapshot in one step, without mixing parts of old and new versions.
Policy propagation is eventual
The standard terms contain no fixed policy-propagation or global-revocation deadline. A successful update means the policy was saved durably. It does not prove that every permission-checking component has received and applied the change. Checking one component, reading the policy store, or obtaining an Explain report does not prove that every component has the latest policy. Work already authorized and in progress is not cancelled by a later policy update. An older otherwise valid snapshot can explain a decision made shortly after a policy update. The adapter must still distribute updates as documented; it cannot keep using old policies indefinitely. Support checks which policy versions the components have and whether updates are reaching them. If your application requires an immediate global revocation deadline, discuss that requirement before choosing these terms. The standard terms do not provide an immediate global revocation deadline.Scaling and limits
The standard production model automatically adds adapter capacity within the agreement’s workload limits. Each new permission-checking component must load usable policies before handling requests. Starting an instance does not make it ready to check permissions. Decision cost depends on policy and entity representation, conditions, context and matching behavior. Policy distribution and shared administration state can constrain growth even when decision execution is local. A workload combining policy administration, STS, and permission checks needs its own agreed limits. No numerical maximum decision or administration rate is assigned here. An approved limit must describe completed decisions or operations, policy complexity, memory demand, components ready to enforce permissions, update traffic, allowed traffic bursts and spare capacity for failures. Correct denies count as evaluated decisions; failures caused by unusable adapter policy data do not.Worked example: authorize an object request
An application sends a supported S3 operation to an enforcing adapter with usable policy state. The authorizer constructs the principal, action, resource and context, evaluates the applicable policy, and enforces the result. Both a correct permit and a correct deny are valid outcomes. Preparing and evaluating the decision count toward the permission-check latency target. If allowed, the request continues to the target service. The object operation has its own timing measurements.Worked example: unavailable or recently changed policy state
If a permission-checking component cannot load usable policies, refusing the request prevents unsafe access. Support still records this as an adapter failure, not an intentional policy denial. If the problem instead follows a role-policy update, compare the saved policy update with the policy version used by the permission-checking component. If the component used an older valid policy version, investigate whether the update reached it. If it decided incorrectly under the version it used, investigate policy evaluation or enforcement. The HTTP status alone cannot tell you which happened.Evidence for support
Preserve the affected application operation, permission check, or policy-administration operation, sanitized policy structure, relevant revision identifiers, result, timestamps and request identifiers. Describe policy-size or update-frequency changes that preceded the incident. Use an Explain report to inspect the evidence it actually captured. It cannot prove decisions it did not capture or show that every component has the latest policy.x-t9-explain: true executes the request while recording an explanation, so do not replay policy mutations to gather evidence without considering their effects.
Never include credentials, signed tokens, session secrets or unredacted sensitive policy context in a support bundle. Tensor9 can help investigate with redacted policy structure and request identifiers; you do not need to prove whether evaluation, propagation or state availability was responsible before requesting help.