IAM
Beginner 13 min read IAM

Identities and Principals

Who and what acts in your cloud

IAM starts with principals: users, groups, roles and service identities. Who or what can act in your cloud, and how they prove who they are, is the identity layer everything else hangs on.

IAMprincipalusergrouproleservice accountidentity
Prerequisites: Cloud Account Structure
Before we start

What you will learn

  • Distinguish users, groups, roles and service identities
  • Explain principals per cloud (AWS IAM, Entra ID, GCP IAM)
  • Design identity that separates humans from machines
In 60 seconds

A principal is any entity that can make an API call: users (humans), groups (collections), roles (assumable), and service identities (machines, service accounts, managed identities). Identity proves 'who' before policies decide 'what'.

Introduction

What is this?

IAM identity: AWS has IAM users, groups, roles, and instance profiles; Azure has Microsoft Entra ID users/groups, service principals and managed identities; GCP has Google identities, IAM service accounts, and workload identity. Principals carry credentials (password, keys, tokens) and are mapped to policies that authorize actions. Design separates humans (long-lived but MFA-gated) from machines (short-lived, scoped tokens).

Motivation

Why do you need it?

  • Nearly every 'who has access to what' question is an identity question.
  • Federated/SSO identity centralizes onboarding and offboarding ({ha {the} ex-employee problem}).
  • Machine identities scale past humans: CI pipelines, services, Lambda/containers need them.
  • Blast radius shrinks when identities are least-privilege and scoped.
Think about it

Mental model

Imagine

Building badges: staff badge, visitor badge, and a robot badge

Think of

IAM identities

Staff (users) have a badge with photo (MFA). Visitors (roles) are issued a temporary pass at the desk. Robots (service accounts) get a badge that opens only the doors their machine needs. All prove who/what is at the door before the door decides.

Mechanics

How it works

  • AWS: IAM user (person/access), IAM role (assumed by users/services/cross-account), instance profile (role for EC2/ECS).
  • Azure: Entra ID users/groups; service principals are the app identity; managed identities are system-assigned/service-assigned identities Azure rotates.
  • GCP: every Google account is an identity; IAM service accounts are machine identities (key-protected); workload identity federation for cross-cloud.
  • Credentials prove identity: user password/MFA, access keys, OIDC tokens, x509 keys for GCP SAs.
  • Policies attach to principals (identity-based) or resources (resource-based); both are evaluated.

Identity layer.

Humans
Machines
Federation
Credentials
Policies
Real world

In production

  • A company centralizes SSO via Entra ID with MFA and auto-deprovisions users from SAML to AWS.
  • CI pipelines run with OIDC/workload identity — no long-lived keys in config.
  • An EC2 fleet uses instance profiles so code never stores credentials.
Guidelines

Best practices

  • Humans: federated SSO + MFA; machines: scoped service identities with rotating tokens.
  • Use groups, not per-user grants, so lifecycle is managed once.
  • Deprovision fast: offboarding an identity also kills its tokens.
  • Audit identities: list users/service accounts with keys yearly, remove stale ones.
Watch out

Common mistakes

  • Hardcoding a long-lived access key in a Lambda environment variable.
  • Everyone in one 'admins' group with broad powers.
  • Sharing an IAM user across teammates (no audit trail per person).
  • Service accounts given Owner/Editor forever.
Root cause analysis

Common issues

Error
CI can't deploy but prod logs show allow
Root cause

CI uses a different (deleted or scoped) service account

Fix

Confirm the OIDC subject/role mapping and the credential's scopes.

Error
New hire can't see the dev console
Root cause

User not added to the right group or SSO not propagated

Fix

Add to the group and wait for directory sync/provisioning.

Error
Service key leaked in a repo
Root cause

Key stored in source control

Fix

Rotate immediately, scan the repo, switch to workload identity/OIDC.

When things break

Debugging tips

  • Who caused that change? Check audit logs (CloudTrail, activity log) keyed by principal/name.
  • Permission denied? Verify the identity's effective policy and the credential being used.
  • Machine loops: confirm the service account has the exact actions the workflow needs.
  • For federated users, trace the IdP session and the mapped role.
Interviews

Interview checkpoint

Practice

Hands-on lab

Model an Identity Matrix Locally
25 min · beginner
In progress
Objectives
  • Enumerate users, groups and service identities for a small org
  • Decide which credential strategy fits each
  • Produce an audit-friendly matrix

Model an Identity Matrix Locally

25 min · beginner

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

Quick quiz

0/2
1

Which of the following is a machine identity?

2

Groups let you manage entitlements for many users at once.

Go deeper

Official documentation

AWS — IAM users, groups, roles
docs
Azure — Managed identities
docs
GCP — Service accounts
docs