On this page
Why IAM is the foundation of cloud security
Almost every cloud breach you read about starts the same way: a credential or permission that was broader than it needed to be. Not a clever zero-day, just an access key with too much power, or an S3 bucket open to everyone. IAM (Identity and Access Management) is the system that decides who can do what. Get it right and most attack paths simply close.
It feels intimidating because of the jargon, principals, policies, roles, ARNs. But underneath, IAM answers exactly one question for every single request:
Is THIS identity allowed to perform THIS action on THIS resource, yes or no?
Who this is for
Beginners. If you've ever gotten an "Access Denied" and not known why, this article is for you.
The four words: who, what, which, allow/deny
- Principal, the identity making the request. A human user, or (better) a role assumed by a service or app.
- Action, the specific operation, namespaced by service:
s3:GetObject,ec2:StartInstances. - Resource, the exact thing, named by an ARN (Amazon Resource Name):
arn:aws:s3:::my-bucket/*. - Effect,
AlloworDeny. Everything is denied by default; you grant access explicitly.
How a request is actually evaluated
Every API call runs this gauntlet. Default is deny; an explicit Deny always wins over any Allow.
- 1
Start from DENY
Nothing is allowed until something explicitly allows it. This is the single most important IAM rule.
- 2
Look for a matching Allow
AWS gathers every policy attached to the principal and the resource, and checks for an Allow matching this action + resource.
- 3
Check for any explicit Deny
If any policy says Deny for this request, it's denied, full stop. An explicit Deny beats any Allow.
- 4
Decide
Allowed only if there is a matching Allow and no matching Deny. Otherwise: Access Denied.
What a policy actually looks like
A policy is just JSON listing statements of effect + action + resource. This one lets a principal read objects from one bucket, and nothing else:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::reports-bucket/*"
}
]
}Read it as a sentence: *Allow the action s3:GetObject on every object in reports-bucket.* No write, no delete, no other bucket. That's least privilege, grant exactly what's needed, nothing more.
Users vs roles: prefer roles, always
The biggest practical upgrade you can make: stop handing out long-lived access keys, and use roles instead.
| IAM User (keys) | IAM Role | |
|---|---|---|
| Credentials | Long-lived access key | Short-lived, auto-rotated |
| If leaked | Valid until you notice + revoke | Expires in minutes/hours |
| Best for | Rare human/CLI cases | Apps, services, EC2, Lambda, CI |
| Rotation | Manual (often forgotten) | Automatic |
The #1 cloud security mistake
Hardcoding long-lived access keys in code, config, or a Git repo. Leaked keys are the most common breach vector. Use roles so credentials are temporary and rotate themselves.
Common mistakes that cost people (a lot)
- Using the root account for daily work. Lock it away, enable MFA, and never use it for routine tasks.
- **Granting
*permissions "to make it work."**Action: "*"onResource: "*"is admin-over-everything. Scope it down. - Long-lived access keys in code or Git. Use roles and short-lived credentials. Scan repos for leaked keys.
- No MFA on human users. A password alone is one phishing email away from compromise.
- Never auditing. Permissions accumulate. Review and remove what's unused, least privilege is a habit, not a one-time setup.
Where to go next
The whole article in 6 lines
- IAM answers one question: **can THIS identity do THIS action on THIS resource?**
- Four parts: **principal, action, resource, effect (Allow/Deny).**
- **Everything is denied by default;** you grant access explicitly.
- An explicit **Deny always beats an Allow.**
- Practice **least privilege**, grant exactly what's needed, nothing more.
- Prefer **roles** (short-lived credentials) over users with long-lived keys.
- Go deeper: Service Auth & IAM.
- Related read: Zero Trust Networking, where IAM meets the network.
- See it in context in the Cloud Engineer path.
Want to go deeper?
This article covers concepts taught hands-on in the Cloud Engineer and DevOps career paths, with real terminal labs, production scenarios, and structured lessons.