Iam design

IAM design

Identity is the real security perimeter in the cloud. The design goal: every principal holds the least it needs, nothing is permanent, and the whole arrangement is reviewable by a human in an afternoon.

Method

1. Grant to roles, never to individuals. Humans assume roles (engineer, oncall, auditor) through SSO group membership; workloads get per-service roles. Direct user grants are unreviewable snowflakes; when the org chart changes, group membership changes and IAM follows.
2. Kill long-lived credentials. Humans: SSO with MFA into temporary session credentials. Workloads: platform-issued identity (instance profiles, workload identity, OIDC federation from CI), never access keys in env vars or repos (see secrets-management). Any static key that must exist gets rotation and a usage alarm.
3. Scope by resource and condition, not service-wide stars. s3:GetObject on arn:...:bucket/tenant-a/*, conditions on VPC source, tags, or org ID. Action: * on Resource: * grants appear in incident reports, not designs. Separate read from write roles; most consumers only need read.
4. Cap delegation with permission boundaries. Teams that create roles (platform, CI) operate under boundaries that cap what any role they create can do; org-level policies (SCPs) deny the never-events globally: leaving allowed regions, disabling audit logs, making buckets public. This is how self-service and safety coexist.
5. Make elevation an event. Break-glass admin via just-in-time elevation: time-boxed, ticket-linked, alerting on use, reviewed after. Standing admin should be near zero; if oncall needs admin nightly, the runbooks need better scoped roles instead.
6. Review with data, not memory. Access analyzers and last-used data flag unused permissions and external-facing grants; prune quarterly. Alert on privilege-escalation primitives specifically: iam:PassRole with broad scope, policy-attach rights, and role trust edits are the paths from "some access" to "all access".

Boundaries

• IAM is authorization for cloud APIs; your application's user-facing permissions are a separate model (see authz-design), and conflating them couples tenants to your infrastructure.
• Least privilege that blocks daily work gets bypassed with shared roles; iterate scopes with the teams or lose the whole game.
• Multi-account/project separation is the coarse isolation IAM rides on; if everything lives in one account, boundaries are doing a job accounts should.