IAM Fundamentals on GCP

Identity and Access Management (IAM) is the foundation of security on Google Cloud Platform. It answers three questions for every request: Who is making the request? What are they trying to do? On which resource? Mastering IAM is essential for securing your cloud environment.

---

The IAM Model

Every access decision in GCP follows the same pattern:

Member  (WHO)   +   Role  (WHAT)   =   Binding on Resource  (WHERE)
────────────────    ─────────────       ───────────────────────────────
user:alice@co.com   roles/viewer        project: my-project
group:devs@co.com   roles/compute.admin folder: engineering
serviceAccount:...  roles/storage.admin organisation: 123456789

An IAM policy is a collection of bindings, each pairing one or more members with a role on a resource.

---

Members (Identities)

A member is an identity that can be granted access. GCP supports several member types:

Member Type	Format	Example
Google Account	user:email	user:alice@example.com
Service Account	serviceAccount:email	serviceAccount:my-sa@proj.iam.gserviceaccount.com
Google Group	group:email	group:developers@example.com
Google Workspace domain	domain:domain	domain:example.com
Cloud Identity domain	domain:domain	domain:example.com
allAuthenticatedUsers	Special identifier	Any authenticated Google account
allUsers	Special identifier	Anyone — including unauthenticated (public)

Google Groups — The Recommended Approach

Rather than granting roles to individual users, best practice is to:

1. Create a Google Group (e.g., platform-team@example.com)
2. Add team members to the group
3. Grant IAM roles to the group

This simplifies onboarding (add user to group) and offboarding (remove from group).

---

Roles

A role is a collection of permissions. Permissions are the finest-grained unit of access control in GCP and follow the format:

<service>.<resource>.<verb>

Examples:
  compute.instances.create
  storage.objects.get
  bigquery.datasets.delete

You never grant permissions directly — you always grant roles that bundle permissions together.

Role Categories

Category	Description	Example
Basic Roles	Broad, legacy roles — avoid in production	roles/viewer, roles/editor, roles/owner
Predefined Roles	Google-managed, service-specific	roles/compute.instanceAdmin.v1, roles/storage.objectViewer
Custom Roles	User-defined with hand-picked permissions	projects/my-proj/roles/myCustomRole

---

IAM Policies

An IAM policy is attached to a resource (organisation, folder, project, or individual resource) and contains one or more bindings:

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:alice@example.com",
        "group:analysts@example.com"
      ]
    },
    {
      "role": "roles/storage.admin",
      "members": [
        "user:bob@example.com"
      ]
    }
  ]
}

Policy Inheritance

Policies are inherited down the resource hierarchy and are additive:

Organisation: grant roles/viewer to group:all-staff@co.com
  └── Folder: Engineering
      └── Project: eng-prod
          → all-staff@co.com inherits roles/viewer on eng-prod
          → Additional roles can be granted at the project level
          → Inherited roles CANNOT be removed at a lower level

Deny Policies

Introduced in 2022, deny policies allow you to explicitly deny specific permissions, overriding any allow policies:

# Deny policies are managed via the IAM v2 API
# They take precedence over allow policies
# Use cases: prevent accidental deletion, block risky permissions

---

Viewing and Managing IAM

# View the IAM policy for a project
gcloud projects get-iam-policy my-project

# View in JSON format
gcloud projects get-iam-policy my-project --format=json

# Grant a role
gcloud projects add-iam-policy-binding my-project \
  --member="user:alice@example.com" \
  --role="roles/storage.objectViewer"

# Revoke a role
gcloud projects remove-iam-policy-binding my-project \
  --member="user:alice@example.com" \
  --role="roles/storage.objectViewer"

# View all roles available
gcloud iam roles list

# View permissions in a role
gcloud iam roles describe roles/storage.objectViewer

---

The Evaluation Flow

When a request arrives, GCP evaluates access in this order:

1. Deny policies — if a deny rule matches, access is denied immediately
2. Allow policies — if an allow binding grants the required permission, access is allowed
3. Default deny — if no allow binding matches, access is denied

Request arrives
    │
    ▼
Deny policy match? ──Yes──▶ DENIED
    │No
    ▼
Allow policy match? ──Yes──▶ ALLOWED
    │No
    ▼
DENIED (default)

---

Key Terminology

Term	Definition
Permission	The finest-grained unit of access (e.g., compute.instances.start)
Role	A collection of permissions
Binding	A mapping of members to a role
Policy	A collection of bindings attached to a resource
Member	An identity (user, group, service account, domain)
Resource	The GCP entity the policy is attached to

---

Summary

GCP IAM is a policy-based access control system where members are granted roles on resources. Policies are inherited down the resource hierarchy and are additive — a child cannot restrict permissions granted by a parent (though deny policies can override allows). Permissions are never granted directly; they are always bundled into roles. Understanding this model is the foundation for everything else in IAM. Next we will dive into the three role types — basic, predefined, and custom.