When migrating to GCP from AWS some features are front-and-center – like projects & folders. The IAM design differences are a bit less obvious until they bite you.

In order to practice POLP (Principle of Least Privilege) on GCP , the hiearchy of IAM permissions will need to be transformed.

Whereas AWS IAM focuses on configuration mapping principles to resources & roles, GCP offers a more prominent inheritance model of Org → Folders → Projects → Resources. Moreover, many resources like service-accounts, buckets can themselves have direct IAM bindings , leading to “hidden” IAM bindings for the unininitiated.

The result means moving bindings up or down the heirarchy when you design IAM for GCP. For example, access to service accounts are managed by binding IAM to the service account itself, whereas AWS might do this through a condition. Access to a storage bucket via direct bindings. And in some cases self-referential bindings, like a SA launching a container as it’s own SA.

Migrators’ Tips when Setting Up GCP IAM Bindings

  • create groups (collections of users / principals) for managing roles
  • Define the ORG / Folder / Project structure first – remembering that inheritance flows downward. Access & firewalls granted at the top inhert to assets below
  • Audit regularly with Recommendations & Security Command Center
  • Apply roles/ServiceAccountTokenCreator sparingly and at the SA level to minimize access . e.g. allow “gcp-developers@” access to “CloudBuild@” service account
gcloud iam service-accounts add-iam-policy-binding \
    cloudbuild@${PROJECT_ID}.iam.gserviceaccount.com \
    --member="group:gcp-developers@example.com" \
    --role="roles/iam.serviceAccountTokenCreator"

Cloud Permissions Model Comparison: AWS vs. GCP

Understanding the design differences is key to handling a migration. Here are key differences that will influence how you transform your IAM policies when migrating to GCP

Feature AWS IAM GCP IAM
Hierarchical Focus Resource-Centric Hierarchy-Centric
Primary Inheritance Less emphasis on automatic inheritance; requires explicit granting via Policy Attachment. Strong top-down inheritance from Organization → Folder → Project.
Identity Entity IAM User, IAM Role (the principal) Member (Google Account, Service Account, Group, or Domain)
Policy/Configuration Format JSON policy documents attached to Users, Groups, or Roles. IAM Bindings (who, what, where) that map a Member to a Role.
Core Access Definition Policy (a document defining specific Actions like s3:GetObject on specific Resources). Role (a collection of permissions like compute.instances.start) assigned to a member.
Access Granularity Highly granular, down to individual API Actions (e.g., ec2:TerminateInstances). Granular via Custom Roles and Primitive/Predefined Roles (e.g., roles/compute.viewer).
Default Security Posture Implicit Deny by default; requires explicit Allow statement in a policy. Implicit Deny by default; requires explicit Binding to a Role.
Overarching Governance Service Control Policies (SCPs) applied at the AWS Organization level. IAM policies applied at the Organization and Folder levels.