Cloud Security
Beginner 20 min read Cloud Security

Identity and Access Management Basics

Control who can touch what in the cloud: users, roles, policies, and least privilege as enforceable code rather than good intentions.

IAMrolespoliciesleast privilegeservice accountscredentials
Introduction

What is this?

Cloud IAM is the system of identities (human and machine), permissions (policies), and the mechanics to grant exactly the access each one needs, no more.

Motivation

Why do you need it?

  • IAM is the number-one cause of cloud data exposure — an over-permissive role or exposed key is the story of most breaches.
  • It is the control with the fastest blast-radius reduction: a least-privilege policy is cheaper than any breach response.
  • Modern cloud security is fundamentally an identity game; everything else is a wall behind IAM.
Think about it

Mental model

Imagine

A building pass

Think of

A pass that opens every door, forever

You designed it for the employee of the month; you shipped it to everyone so you could skip keeping it updated.

Mechanics

How it works

  • An identity (user, role, or service account) carries a policy: an allow/deny statement over actions and resources.
  • AWS evaluates explicit deny before allow; Azure uses role assignments on scope; GCP binds roles to members (IAM policy).
  • Roles abstract permissions from humans: 'EC2Operator' instead of a pile of raw actions, so people rotate through roles.
  • Credentials (keys, tokens) give the identity legs; rotation and scoping limit how far a leaked key walks.

A least-privilege request evaluation

Actor
Policy
Scope
Allow
Audit
Real world

In production

  • A fintech replaces a standing admin key with short-lived credentials via an IAM-linked service so rotation is automatic.
  • A company roles out cross-account roles with 'read-only on one S3 bucket' grants instead of dumping full access.
  • A startup's infra team uses Infrastructure-as-Code to review every IAM change as a diff in CI.
Guidelines

Best practices

  • Default to deny and add the smallest allow; grant by role, not by person-copy.
  • Prefer short-lived or federated credentials over long-lived access keys.
  • Rotate keys on a cadence; revoke instantly on termination or compromise.
  • Make IAM changes reviewed diffs, peer-reviewed, with a reason field.
Watch out

Common mistakes

  • Creating one 'break-glass admin' key and reusing it for routine deploys 'temporarily'.
  • Granting 'AdministratorAccess' to a service role because debugging is easier.
  • Sharing a single service-account key across a team on the wiki.
  • Never revoking: an offboarded employee's role still existing in the policy is a ticking bomb.
When things break

Debugging tips

  • Use the provider's policy simulator/azure effective permissions to see why a request is denied.
  • When 'it worked before', diff the last IAM change — those diffs are the smoking gun.
  • Prefer the audit log to guesswork: every denial is recorded with the identity and action.
Security

Security considerations

  • Treat a leaked key as compromised: rotate, revoke, and inspect what it could touch in the previous window.
  • Machine roles should be least-privilege too — a container role with delete-everything is a P0 waiting.
Interviews

Interview checkpoint

Practice

Hands-on lab

Build a Least-Privilege Policy and Prove It in a Local Emulator
45 min · beginner
In progress
Objectives
  • Write a policy that grants read-only on one bucket to a named role.
  • Provision a local emulator (minio/localstack) and attach the role.
  • Prove the role can read its bucket but cannot write or touch another.

Build a Least-Privilege Policy and Prove It in a Local Emulator

45 min · beginner

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

The strongest protection against a leaked long-lived key is...

2

least privilege means...

Go deeper

Official documentation