Cloud Identity & Access (IAM) From First Principles

#aws #iam #security #leastprivilege

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?

Note: 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

In the real world	In tech
👤 Who is asking	Principal (user / role)
🎬 What they want to do	Action (e.g. s3:GetObject)
📦 Which thing	Resource (an ARN)
✅ Yes or no	Effect (Allow / Deny)

Every IAM concept is one of these four everyday ideas.

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, Allow or Deny. Everything is denied by default; you grant access explicitly.

How a request is actually evaluated

This part is interactive in the original. Open the full version on TheSimplifiedTech

Start from DENY: Nothing is allowed until something explicitly allows it. This is the single most important IAM rule.
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.
Check for any explicit Deny: If any policy says Deny for this request, it's denied, full stop. An explicit Deny beats any Allow.
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:

read-one-bucket.json

{
  "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

Roles give out short-lived, auto-rotating credentials, far safer than static keys.

Warning: 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: "*" on Resource: "*" 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.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.