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](/service-adapters/catalog).