SYSTEM Cited by 4 sources

AWS Identity and Access Management (IAM)¶

What it is¶

AWS Identity and Access Management (IAM) is AWS's per-partition authorization system — the service that evaluates whether a given principal is allowed to take a given action on a given resource under a given set of policies. Combined with AWS STS for short-lived credentials, IAM Identity Center for federation, Organizations for multi-account policy hierarchy (via SCPs), and Cedar / the AWS policy interpreter for the policy semantics.

The per-partition property¶

A central architectural fact across the sovereign-failover literature: IAM is bound to an AWS partition. "Each partition is a logically isolated group of AWS Regions with its own set of resources, including AWS Identity and Access Management (IAM). Because of this separation, partitions act as hard boundaries. Credentials don't carry over." (Source: sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty)

This property is what forces cross-partition auth to be an explicit architecture problem rather than a transparent capability.

Cross-partition IAM design patterns¶

When an identity in one partition must act against a resource in another partition, IAM provides five composable tactics (Source: sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty):

IAM roles with trust relationships + external IDs
STS regional endpoints
Resource-based policies
Cross-account roles via Organizations
Federation from a centralized IdP (patterns/centralized-identity-federation)

Stub page¶

This page exists to anchor IAM's role in the cross-partition failover and centralized-federation patterns. AWS IAM also surfaces in the automated-reasoning work (Cedar, Zelkova, IAM Access Analyzer) — see that page for the formal-methods lineage.

OIDC Identity Provider + web-identity federation¶

IAM exposes an Identity Provider resource type for registering an external OIDC IdP ("arn:aws:iam::<account>:oidc-provider/<issuer-host>/<path>"), after which a Role's trust policy can name that IdP as its Federated principal with action sts:AssumeRoleWithWebIdentity. Combined with STS's AssumeRoleWithWebIdentity API, this lets non-AWS workloads (GitHub Actions, EKS Pods via IRSA, Fly Machines, etc.) obtain AWS credentials without any long-lived AWS keypair. See OIDC federation for cloud access and patterns/oidc-role-assumption-for-cross-cloud-auth.

Canonical wiki walkthrough: the Fly.io AWS without Access Keys post, which ships the full trust-policy shape (Principal.Federated = IdP ARN, Condition.StringEquals on aud, Condition.StringLike on sub) and the observation that "this is a rare instance where you can reasonably drive the entire AWS side of the process from within the web console." Most cross-cloud IAM federation today happens through this path.

Seen in¶

sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty — names IAM as the load-bearing per-partition resource that forces the cross-partition auth problem.
sources/2026-02-17-allthingsdistributed-byron-cook-automated-reasoning-trust-ai — the AWS policy interpreter (IAM internals) as a decade of automated-reasoning work.
sources/2026-02-05-aws-convera-verified-permissions-fine-grained-authorization — Convera's Cedar policy governance gates policy authorship behind a strictly-regulated IAM role: Convera's infosec team owns policy edits via IAM, while runtime evaluation is via AVP (patterns/lambda-authorizer
API Gateway). IAM here draws the line between write-side governance and read-side evaluation — an idiomatic concepts/policy-as-data split.
sources/2026-04-21-figma-how-we-built-a-custom-permissions-dsl — IAM policy structure (effect + action + resource + condition) as the direct design inspiration for Figma's in-house permissions DSL. Figma quote: "IAM policies are notoriously hard to work with and are definitely not universally loved. But for us, they provide granularity and isolation, a key part of our system: A policy author could write an IAM policy and not have to worry about all the other existing IAM policies." IAM is rejected as a substrate (not designed for application-level resources, no runtime for this shape of policy), but its compositional isolation property transferred directly. See concepts/permissions-dsl, patterns/deny-overrides-allow.
sources/2024-06-19-flyio-aws-without-access-keys — IAM's Identity Provider resource + AssumeRoleWithWebIdentity trust-policy shape as the AWS side of the Fly.io → AWS OIDC federation bridge. Full trust-policy example disclosed (Principal.Federated = oidc-provider/oidc.fly.io/<org>, Condition.StringEquals on aud, Condition.StringLike on the <org>:<app>:* sub prefix). Fly.io quote: "your cloud team adds Roles all the time; this is just a Role with an extra snippet of JSON. The resulting ARN isn't even a secret; your cloud team could just email or Slack message it back to you." Canonical wiki instance of patterns/oidc-role-assumption-for-cross-cloud-auth and patterns/sub-field-scoping-for-role-trust.