Day 119: IAM — the part everyone fails
IAM: the part everyone fails
AWS IAM controls who (or what) can do what to which resources — the cloud equivalent of Kubernetes RBAC (Phase 11), and just as easy to over-permission by habit. An IAM policy is a JSON document of allow/deny statements; a role is an identity that can be assumed (by a user, a service, an EC2 instance) without long-lived credentials being embedded anywhere.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::my-bucket/uploads/*"
}]
}Why IAM is "the part everyone fails"
It's common to see "Action": "*", "Resource": "*" policies attached "just to get something working," which then never get tightened. Combined with hardcoded long-lived access keys instead of roles, this is one of the single most common root causes of real cloud security incidents — not exotic zero-days, just overly broad IAM.
Prefer roles (assumed temporarily, auto-rotating credentials) over IAM users with static access keys wherever possible — an EC2 instance or EKS pod assuming a role never has a long-lived secret sitting in a config file at all.
Key terms
- IAM policy
- A JSON document defining allowed/denied actions on AWS resources.
- IAM role
- An assumable identity with temporary credentials, avoiding long-lived static keys.
Why is a long-lived IAM access key embedded in application config considered a significant risk compared to an assumed IAM role?
