Learn Cloud Computing - Identity & Access Management (IAM) Deep Dive

#Introduction

In episode 2, you understood the shared responsibility model: "security IN the cloud" — the data and access layers — is your responsibility. Episode 3 covers the primary tool for that responsibility: Identity & Access Management (IAM).

IAM is the system that decides who can access what in the cloud. It sounds simple, but it's the leading cause of data breaches — not application bugs, but overly permissive entitlements. This episode dissects the concepts, components, and IAM practices across AWS, GCP, and Azure side by side.

#Authentication vs Authorization

Two words that are often mixed up, even though they are different stages:

• Authentication — answers "who are you?". Proving identity via password, MFA, or credentials. Analogy: showing your ID card at the building entrance.
• Authorization — answers "what are you allowed to do?". Once identity is proven, the system checks permissions. Analogy: after entering the building, your access card determines which rooms you may open.

Authentication without authorization is like having the building key but being free to enter every room — unsafe. Authorization without authentication is like having a permission list but not knowing who's coming in — useless. The cloud needs both.

#The Principle of Least Privilege and Zero Trust

Two principles drive all modern IAM design:

• Least privilege — grant the minimum permissions needed to complete a task, no more. If an application only needs to read files, don't give it permission to delete.
• Zero trust — never trust by default, no matter where the request comes from. Every access is verified, even requests originating inside your own network.

Use an analogy: at an airport, baggage technicians have access to the baggage area, not automatically to the pilot's cabin. If one permission leaks, the damage possible is limited to that permission's area. This is the blast radius concept — the smaller the permission, the smaller the area that can be blown up if credentials leak.

#AWS IAM Components

AWS builds IAM from five components:

• User — an identity for humans (building applications, logging in, and so on), with their own credentials.
• Group — a collection of users so permissions can be granted once to many people, for example the developers group.
• Role — an identity not tied to a person, assumed by users, applications, or services. Role credentials are temporary.
• Policy — a JSON document that defines permissions (this is the heart of IAM, covered below).
• STS (Security Token Service) — the service that issues temporary credentials for role assumption (covered in episode 4).

The AWS model: permissions are attached to users, groups, or roles through policies; the final evaluation is the union of all applicable policies.

#GCP IAM Components

GCP uses a different approach: service accounts and policy bindings.

• Service account — an identity for applications and workloads, not humans. It holds keys or uses other credential mechanisms.
• Role — a predefined collection of permissions (for example roles/storage.objectViewer).
• Policy binding — the process of "attaching" a principal (who) with a role (what permission) on a resource (where), written in a per-project IAM policy document.

GCP doesn't follow an explicit-deny model at the base policy level: anyone without a binding has no access — access only exists because a binding exists.

#Azure IAM Components

Azure separates two things that are often treated as one:

• Entra ID (formerly Azure Active Directory) — the identity directory: users, groups, service principals, managed identities, and authentication (login, SSO, MFA).
• RBAC (Role-Based Access Control) — the authorization mechanism: who (principal) gets which role on which scope (subscription, resource group, or resource).

On Azure, you log in via Entra ID, then access is checked by RBAC. Managed identity is an automatic identity for Azure applications that needs no stored secrets at all — analogous to GCP's service account.

#Anatomy of a JSON Policy

On AWS, permissions are written as JSON policies. Understand the basic structure because all providers use similar patterns:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ReadOnlyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::assets",
                "arn:aws:s3:::assets/*"
            ],
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "203.0.113.0/24"
                }
            }
        }
    ]
}

Four key elements:

• Effect — Allow or Deny. Deny always wins over Allow.
• Action — the operations allowed/denied, in service:Operation format.
• Resource — the target object, written as an ARN.
• Condition — additional requirements; the example above restricts access to only the office IP range.

#CLI Practice: AWS, GCP, and Azure

Let's look at the practical form in the CLI. On AWS, manage users and attach policies:

aws iam list-users
aws iam create-user --user-name dev
aws iam attach-user-policy \
  --user-name dev \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
aws iam list-attached-user-policies --user-name dev

The command aws iam list-users lists all users in the account — a quick way to verify who has access. On GCP and Azure, the authorization pattern is assignment-based:

gcloud projects get-iam-policy my-project \
  --flatten="bindings[].members" \
  --format="table(bindings.role, bindings.members)"

az role assignment list \
  --assignee user@example.com \
  --output table

The patterns above highlight a philosophical difference: AWS is oriented around policies attached to identities; GCP and Azure are oriented around bindings between who and role on a scope. The end result is the same — granular access control — but the vocabulary differs.

#IAM Implementation Comparison

The takeaway: whatever the component names, the thought process is the same — who (principal) + what permission (role/policy) + where (scope). Master these three questions, and IAM at any provider becomes easy to understand.

#Conclusion

Episode 3 gives you the language to control cloud access:

• Authentication proves identity; authorization determines permissions.
• Least privilege and zero trust minimize the blast radius.
• AWS uses users, groups, roles, and policies; GCP uses service accounts and bindings; Azure uses Entra ID and RBAC.
• A JSON policy is a permission document: Effect, Action, Resource, and Condition.

In episode 4, you'll learn to practice all of this safely: why the root account shouldn't be used for daily work, the dangers of API keys that live forever, and using temporary credentials and audit logging to minimize risk.