iam-best-practices

• SKILL.mdcore · 6,674 bytes
• SKILL.mdcore · 6,674 bytes
• metadata.jsonasset · 1,480 bytes
• references/escalation-paths.mddoc · 4,769 bytes
• references/verifying-findings.mddoc · 3,174 bytes

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/iam-best-practices/SKILL.md. -->

# Identity & Access Management Best Practices

Least-privilege cloud IAM: policy scope, privilege-escalation paths, permissions boundaries, workload identity over static keys, MFA enforced by policy, cross-account trust, and separating deploy from runtime. Use when generating IAM policies, roles, or trust documents, wiring CI/CD service accounts or workload identities, delegating role creation, or designing cross-account access.

## ALWAYS

- Grant the minimum permissions the workload's stated job requires: deny by default, then add concrete actions against concrete resources. A wildcard action on a wildcard resource — in a custom policy, in `AdministratorAccess`, or in `iam:*` attached to something that runs continuously — is the same finding wearing three different names.
- Read a policy for the **privileges it can reach**, not only the ones it names. A principal that can write policy (`iam:PutRolePolicy`, `iam:AttachRolePolicy`, `iam:CreatePolicyVersion`) can grant itself anything, and a principal that can pass a role into a compute service it may also create (`iam:PassRole` with `lambda:CreateFunction`, `ec2:RunInstances`, `glue:CreateJob`) inherits that role's privileges. These read as narrow grants and are administrative ones. `references/escalation-paths.md` lists the combinations worth failing a review over.
- Bound delegated permissions with a **permissions boundary** or an organization-level policy (SCP, GCP org policy, Azure management-group policy) when teams may create their own roles. The boundary caps what any role they create can do, which is what makes self-service role creation safe rather than a privilege-escalation primitive.
- Prefer **workload identity** — IRSA on EKS, GKE Workload Identity, Azure Managed Identity, OIDC federation from CI — over a static key. The goal is that no long-lived credential exists to leak. Where one is genuinely unavoidable, give it a documented rotation cadence and automatic disablement on inactivity, and treat that as a temporary state rather than the steady state.
- Enforce MFA for human principals through a **policy condition** (`aws:MultiFactorAuthPresent`), not only a directory setting, so a credential that bypasses the directory still cannot act.