AWS IAM

On this page

• Coverage by target cloud
• How the targets compare
  • Max adaptation
  • Infrastructure-only adaptation
• On Google Cloud, Azure, OCI, and Private Kubernetes
  • Via Cedar
• On Google Cloud
  • Via IAM
• On Azure
  • Via IAM
• On OCI
  • Via OCI IAM

​

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, plus GetCallerIdentity, 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.

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. Configure AWS_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. IAM Allow 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 matching forbid 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 support aws: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 implement SimulatePrincipalPolicy 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 as iam: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 as iam: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 as iam: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 Catalog.