Set Up IAM Roles

Least-priv.

Overview

IAM roles are the AWS primitive that lets workloads authenticate without static credentials. The discipline is least-privilege: roles grant only the API actions a workload actually needs, scoped to the resources it actually touches. Role count is irrelevant; what matters is that no role has *:* and that every permission has a documented reason.

• Least-privilege by default. Roles grant only the actions and resources actually used. Compromise of one workload no longer means account-wide access.
• Role assumption via STS. Workloads assume roles through STS; long-lived access keys disappear. Credential theft surface shrinks dramatically.
• Trust policies and permission boundaries. Trust policy says who can assume; boundary caps the maximum permissions even if the role policy is overly broad.
• IAM Access Analyzer plus IRSA. Access Analyzer surfaces over-broad permissions and external-account exposure; IRSA / Workload Identity binds Kubernetes ServiceAccounts to roles cleanly.

The approach

Three habits keep IAM tractable: start with AWS-managed policies for speed, narrow to inline policies as actual usage patterns emerge, and manage everything through Terraform or CDK so changes are reviewed, not console-clicked.

• Start with AWS-managed policies. Reasonable defaults to ship fast. Replace later when usage patterns are known.
• Narrow over time using CloudTrail evidence. CloudTrail and Access Analyzer show which actions a role actually used. Inline policies replace managed ones based on real data.
• Terraform or CDK managed. Console edits are caught and reverted. Audit trail comes free.
• IRSA / Workload Identity plus documented rationale. Kubernetes workloads use OIDC-bound service accounts; per-role the why-it-exists lives in the IaC repo.

Why this compounds

Each tightened role reduces blast radius. The cumulative effect across an estate is the difference between a contained breach and a full account compromise. The team's understanding of which AWS APIs each service actually needs deepens over time.

• Breach impact reduced. A compromised workload reaches only the resources its role explicitly allowed.
• Service permission inventory. Role policies document service-to-AWS-API relationships. The estate becomes mappable.
• Compliance posture improved. Least-privilege satisfies SOC 2, ISO 27001, and FedRAMP controls without bespoke remediation.
• Year-one investment, year-two habit. The first cleanup is heavy. By year two, every new service ships with a least-privilege role on day one.