GCP IAM vs. AWS IAM: A Deep Dive into Architectural Differences
While both Google Cloud Platform (GCP) and Amazon Web Services (AWS) Identity and Access Management (IAM) systems share the same goal—controlling who can do what on which resources—they are built on fundamentally different architectural philosophies.
Understanding these differences is crucial for multi-cloud engineers, as applying AWS logic to GCP (or vice versa) often leads to security gaps or unmanageable complexity.
1. Resource Hierarchy and Inheritance
The most significant difference lies in how resources are organized and how permissions cascade.
AWS: The Account Boundary
AWS uses a flat isolation model. The primary container is the AWS Account. While AWS Organizations allows grouping accounts, the IAM Reference is generally scoped to the specific account.
- Isolation: By default, resources in Account A are completely invisible to Account B.
- No Inheritance: Creating a user in a "parent" organization unit does not automatically give them access to child accounts; you must explicitly provision roles in those accounts.
GCP: The Directory Hierarchy
GCP uses a hierarchical model similar to a traditional file system or an LDAP directory.
- Structure: Organization Node $\rightarrow$ Folders $\rightarrow$ Projects $\rightarrow$ Resources.
- Inheritance: This is key. If you grant a user the
Storage Adminrole at the Folder level, they automatically possess that permission for every Project and every Bucket inside that folder.
[Image of GCP resource hierarchy diagram]
- Benefit: This makes centralized governance much easier but requires careful management to avoid accidentally granting broad access via a high-level binding.
2. Definition of "Roles"
The term "Role" means something entirely different in each cloud.
AWS IAM Role: An Identity
In AWS, a Role is an Authentication entity (a Principal). It is something you "assume."
- A user doesn't "have" a role; a user "assumes" a role.
- When assuming a role, the user temporarily trades their original identity for the role's identity and permissions.
- Use Case: Cross-account access, EC2 instance profiles, Lambda execution identities.
GCP IAM Role: A Collection of Permissions
In GCP, a Role is purely a Authorization construct. It is a collection of permissions (e.g., compute.instances.start, storage.buckets.get).
- A user is "bound" to a role.
- You do not "assume" a role; you are granted the role attached to a specific resource hierarchy.
- Use Case: Grouping granular API permissions into a readable job function (e.g., "Network Admin").
3. How Policies are Applied (Binding vs. Attachment)
AWS: Policy Attachment
In AWS, you create a JSON policy document (Allow/Deny statements) and attach it to a User, Group, or Role.
- Logic: "User Alice has a policy attached that says she can touch Bucket X."
- Deny-by-Default: Everything is denied unless explicitly allowed. An explicit Deny overrides an Allow.
GCP: Policy Binding
In GCP, you create a standard IAM Binding on a resource (or project/folder). A binding connects three things: A Principal (User/Service Account), a Role (Collection of permissions), and the Resource (Scope).
- Logic: "Project A has a binding that says User Alice acts as an Owner."
- Additive: Permissions are generally additive. If Alice has
Viewerat the Organization level andEditorat the Project level, she is an Editor on that project.
4. Service Accounts vs. Instance Profiles
How do virtual machines and applications identify themselves?
AWS: Instance Profiles
You create an AWS IAM Role and assign it to an EC2 instance (via an Instance Profile). The application on the EC2 instance queries the local metadata service to get temporary credentials for that role. The identity is the Role.
GCP: Service Accounts
You create a specialized Google account called a Service Account. This account is a resource itself (it lives in a project). You attach this Service Account to a VM. The identity is the Service Account itself (e.g., my-app@my-project.iam.gserviceaccount.com).
- Key Difference: In GCP, Service Accounts are both principals (they can do things) and resources (users can be given permission to "act as" a service account).
Summary Comparison Table
| Feature | AWS IAM | GCP IAM |
|---|---|---|
| Primary Scope | AWS Account (Hard boundary) | Project (Soft boundary within Hierarchy) |
| Permission Inheritance | No (Requires explicit cross-account trust) | Yes (Flows down from Org $\rightarrow$ Folder $\rightarrow$ Project) |
| "Role" Definition | An identity you assume (Principal) | A collection of permissions (Permission Set) |
| Machine Identity | IAM Role (Instance Profile) | Service Account |
| Policy Style | JSON (Resource & Identity based) | Bindings (Member + Role + Resource) |
| Cross-Context Access | Complex (AssumeRole + Trust Relationship) | Simple (Add user email to target Project IAM) |