Identity and Access Management (IAM)

Note: Cloud infrastructure evolves frequently. While this page covers core IAM concepts, always refer to the official Google Cloud IAM documentation for the most current information.

Google Cloud IAM lets you control who (principals) has what access (roles) to which resources. It provides a unified view of security policy across your entire organization and enforces access control consistently.

Resource Hierarchy

Google Cloud organizes resources in a hierarchy. IAM policies are inherited downward, meaning a policy set at a higher level applies to all resources below it.

  graph TD
    Org[Organization] --> Folder1[Folder]
    Org --> Folder2[Folder]
    Folder1 --> Project1[Project]
    Folder1 --> Project2[Project]
    Folder2 --> Project3[Project]
    Project1 --> Resource1[Resources]
    Project2 --> Resource2[Resources]
    Project3 --> Resource3[Resources]

    style Org fill:#4285F4,color:#fff
    style Folder1 fill:#34A853,color:#fff
    style Folder2 fill:#34A853,color:#fff
    style Project1 fill:#FBBC04,color:#000
    style Project2 fill:#FBBC04,color:#000
    style Project3 fill:#FBBC04,color:#000

Inheritance: Policies set at a higher level (e.g., Organization) are automatically inherited by all resources below. A role granted at the folder level applies to all projects and resources within that folder.

Core Concepts

IAM is built around three core concepts:

  graph LR
    Principal[Principal<br/>WHO] -->|is granted| Role[Role<br/>WHAT]
    Role -->|on| Resource[Resource<br/>WHERE]

    style Principal fill:#4285F4,color:#fff
    style Role fill:#34A853,color:#fff
    style Resource fill:#FBBC04,color:#000

• Principal: The identity requesting access (user, service account, group)
• Role: A collection of permissions that define what actions can be performed
• Resource: The Google Cloud resource being accessed

These are combined in an IAM Policy, which binds principals to roles on a specific resource.

Principals

A principal is an identity that can be granted access to resources. Google Cloud supports several types:

Roles

Roles are collections of permissions. A permission has the format service.resource.action (e.g., compute.instances.start).

Role Types

Basic Roles (Legacy)

Basic roles are the original IAM roles that predate predefined roles. They grant broad permissions across all resources in a project, folder, or organization.

Caution: Avoid using Basic roles in production. They grant far more permissions than most workloads need. Prefer predefined or custom roles that follow the principle of least privilege.

Predefined Roles

Predefined roles are fine-grained roles maintained by Google, typically scoped to specific services. Unlike Basic roles, they grant a narrower set of permissions.

See the full list in the Google Cloud IAM Roles documentation.

IAM Policies

An IAM policy is a collection of bindings that attach roles to principals. Policies are set on resources and inherited by child resources.

Policy Structure

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:alice@example.com",
        "group:developers@example.com"
      ]
    },
    {
      "role": "roles/storage.objectAdmin",
      "members": [
        "serviceAccount:app@my-project.iam.gserviceaccount.com"
      ],
      "condition": {
        "title": "Only production bucket",
        "expression": "resource.name.startsWith('projects/_/buckets/prod-')"
      }
    }
  ]
}

IAM Conditions

Conditions allow you to define conditional access based on attributes like:

• Resource attributes (name, type, tags)
• Request attributes (time, IP address)
• Principal attributes (access levels)

Conditions use Common Expression Language (CEL).

Note: IAM Conditions require policy version 3 and are supported for many, but not all, Google Cloud services.

Service Accounts

Service accounts are special accounts for applications, not humans. They authenticate workloads and can be granted IAM roles.

Types of Service Accounts

Authentication Methods

Prefer keyless authentication (Workload Identity, attached service accounts) over service account keys when possible.

Impersonation

Service account impersonation allows a principal to act as a service account without needing its keys. This is useful for:

• Local development with production-like permissions
• Cross-project access
• Temporary privilege escalation

The principal needs roles/iam.serviceAccountTokenCreator on the target service account to mint tokens. For configuring resources (e.g., Cloud Run, Cloud Functions) to run as a service account, the caller also needs roles/iam.serviceAccountUser.

Organization Policies

Organization policies provide centralized constraints across your resource hierarchy. Unlike IAM (which controls who can do what), organization policies control what can be done regardless of who.

Common constraints:

• constraints/compute.disableSerialPortAccess - Disable VM serial port access
• constraints/iam.disableServiceAccountKeyCreation - Prevent service account key creation
• constraints/compute.restrictVpcPeering - Limit VPC peering connections
• constraints/storage.uniformBucketLevelAccess - Enforce uniform bucket-level access

See all available constraints in the Organization Policy Constraints documentation.

Best Practices

Access Management

• Grant least privilege: Only assign permissions needed for the task
• Use predefined roles: Avoid Basic roles; use service-specific predefined or custom roles
• Use groups over individuals: Assign roles to Google Groups rather than individual users—easier to manage, audit, and adapts to organizational changes automatically
• Review regularly: Revoke unnecessary permissions periodically

Service Account Hygiene

• Create dedicated service accounts per application/workload
• Avoid using default service accounts in production
• Disable unused service accounts
• Avoid service account keys; use Workload Identity instead

Auditing and Monitoring

• Review Cloud Audit Logs for IAM changes and export them (via log sinks) to centralized logging
• Optionally enable Data Access audit logs for sensitive services
• Use IAM Recommender to identify excess permissions
• Use Policy Analyzer to understand who has access to what
• Use Policy Troubleshooter to debug why a principal can or cannot access a resource

Common gcloud Commands

View

Modify

Service Accounts

Impersonation

# Impersonate a service account for gcloud commands
gcloud config set auth/impersonate_service_account SA_EMAIL

# Or per-command
gcloud compute instances list --impersonate-service-account=SA_EMAIL

Troubleshooting

# Check why a principal can/cannot access a resource
gcloud policy-troubleshoot iam \
  --resource="//cloudresourcemanager.googleapis.com/projects/PROJECT_ID" \
  --principal-email=USER@EXAMPLE.COM \
  --permission=PERMISSION

IAM Deny Policies

In addition to allow-based IAM policies, Google Cloud supports deny policies that explicitly block certain permissions, even if they’re granted elsewhere. Deny policies are evaluated after allow policies and are useful for enforcing “never allow X” rules—for example, blocking a sensitive permission organization-wide.

Links to external resources

• IAM Overview
• Understanding Roles
• Service Accounts
• Workload Identity
• Organization Policy Constraints
• IAM Conditions