GCP IAM

IAM stands for Identity and Access Management. It controls who can do what on which resource in GCP. Every action taken in GCP — creating a virtual machine, reading a file, or querying a database — goes through IAM checks first. Without proper IAM setup, either too many people have access (security risk) or too few people can do their job (operational problem).

A simple analogy: IAM is like an office building's key card system. Different employees get access to different floors based on their job role. A developer can enter the server room, but not the finance office. IAM works the same way for GCP resources.

Core IAM Concepts

1. Principal (Who)

A principal is any identity that can request access to a GCP resource. Principals can be:

• Google Account: A person with a Gmail or Workspace email (example: alice@gmail.com)
• Service Account: An identity for an application or a virtual machine, not a human (example: my-app@my-project.iam.gserviceaccount.com)
• Google Group: A collection of Google accounts (example: developers@mycompany.com)
• Google Workspace Domain: All accounts within a company domain
• allUsers: Anyone on the internet (used for public access — use carefully)
• allAuthenticatedUsers: Anyone signed in with a Google account

2. Role (What)

A role is a collection of permissions. Instead of assigning permissions one by one, roles bundle related permissions together. GCP has three types of roles:

Best Practice: Always use Predefined or Custom Roles instead of Basic Roles. Giving someone the Owner role means they can delete everything in the project.

3. Resource (Which)

A resource is any GCP object — a project, a virtual machine, a Cloud Storage bucket, a database, etc. IAM policies can be applied at different levels:

Organization
    └── Folder
        └── Project          ← IAM policy here applies to all resources below
            ├── Compute Engine Instance
            ├── Cloud Storage Bucket  ← IAM policy here applies only to this bucket
            └── Cloud SQL Database

IAM policies are inherited downward. A role granted at the Organization level automatically applies to all projects and resources within it.

How IAM Policy Works

An IAM policy is a list of bindings. Each binding connects a principal to a role on a specific resource.

IAM Policy Example:
┌─────────────────────────────────────────────────────────┐
│  Resource: Cloud Storage Bucket "my-data-bucket"        │
├──────────────────────┬──────────────────────────────────┤
│  Principal           │  Role                            │
├──────────────────────┼──────────────────────────────────┤
│  alice@gmail.com     │  roles/storage.objectAdmin       │
│  bob@gmail.com       │  roles/storage.objectViewer      │
│  dev-team@co.com     │  roles/storage.objectCreator     │
└──────────────────────┴──────────────────────────────────┘

Alice can read, write, and delete objects. Bob can only read. The dev-team group can upload new objects but cannot delete them.

Service Accounts

A service account is a special type of account used by applications and services, not humans. When a virtual machine needs to read from Cloud Storage, it does not use a human's credentials — it uses a service account.

Application on Compute Engine
        │
        │ (authenticates using service account)
        ▼
Service Account: app-reader@my-project.iam.gserviceaccount.com
        │
        │ (has role: roles/storage.objectViewer)
        ▼
Cloud Storage Bucket: "my-data-bucket"
        │
        ▼
Access Granted ✓

Creating a service account via Cloud Shell:

# Create a service account
gcloud iam service-accounts create my-app-sa \
  --display-name="My App Service Account"

# Grant a role to the service account
gcloud projects add-iam-policy-binding my-project-id \
  --member="serviceAccount:my-app-sa@my-project-id.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

Principle of Least Privilege

The most important IAM security rule is: grant only the minimum permissions needed to do the job. Never give the Owner role to an application or a new team member just because it is convenient.

Viewing and Managing IAM Policies

In the Console:

1. Go to IAM & Admin → IAM
2. See all principals and their roles in the current project
3. Click the pencil icon to edit a principal's roles
4. Click Grant Access to add a new principal

Using Cloud Shell:

# View current IAM policy on a project
gcloud projects get-iam-policy my-project-id

# Add a role to a user
gcloud projects add-iam-policy-binding my-project-id \
  --member="user:alice@gmail.com" \
  --role="roles/viewer"

# Remove a role from a user
gcloud projects remove-iam-policy-binding my-project-id \
  --member="user:alice@gmail.com" \
  --role="roles/viewer"

Key Takeaways

• IAM controls who can do what on which GCP resource.
• The three elements are: Principal (who), Role (what), Resource (which).
• Use Predefined Roles instead of Basic Roles for better security.
• Service accounts are used by applications, not humans.
• IAM policies are inherited from Organization → Folder → Project → Resource.
• Always apply the Principle of Least Privilege.