IAM Concepts: Principals, Roles, and Permissions
1. Overview of Cloud IAM
Identity and Access Management (IAM) is the security framework in Google Cloud that defines who (identity) has what access (role) to which resource. In the ACE exam, understanding the relationship between these three elements is critical for solving security and administration scenarios.
The “Hotel Check-in” Analogy
Imagine a high-security hotel:
- Principal (The Guest): You, the person trying to enter.
- Permission (The Action): The ability to open a specific door, use the gym, or access the mini-bar.
- Role (The Keycard): Instead of giving you 50 individual permissions, the hotel gives you a “VIP Guest” keycard. This card is a bundle of permissions (Room access + Gym access + Breakfast access).
- Resource (The Room): The specific physical room or facility you are accessing.
2. Detail Elaboration: The IAM Trinity
Principals (The “Who”)
A principal can be a Google Account (individual), a Service Account (for applications), a Google Group, or a Cloud Identity domain. Key Exam Fact: You cannot add a specific “IP address” as a principal in IAM; IAM deals with identities, not network locations.
Permissions (The “What”)
Permissions are formatted as service.resource.verb. For example:
compute.instances.list: Permission to see VMs.storage.buckets.create: Permission to make new buckets.
Roles (The “Bundle”)
You don’t assign permissions directly to users. You assign Roles. Roles are collections of permissions.
- Primitive Roles: Owner, Editor, Viewer. (Broad, often too much access).
- Predefined Roles: Specifically managed by Google (e.g.,
roles/compute.networkAdmin). - Custom Roles: Created by you for granular control.
3. Core Concepts & Best Practices
Google Cloud follows the Principle of Least Privilege. This means giving a user only the minimum permissions necessary to perform their job, and nothing more.
| Role Type | Granularity | Use Case | Risk Level |
|---|---|---|---|
| Primitive | Coarse-grained | Development/Sandbox only. | High (Over-privileged) |
| Predefined | Fine-grained | Standard production environments. | Low (Recommended) |
| Custom | Ultra-fine-grained | When Predefined roles are too broad. | Medium (Maintenance overhead) |
4. Scenario-Based Decision Matrix
If the requirement is…
- To allow an application on a VM to write to a bucket → Use a Service Account.
- To manage access for a team of 50 developers → Use a Google Group (assign role to group, not users).
- To grant access that automatically applies to all projects in a folder → Assign the Role at the Folder level (Inheritance).
- To restrict a user from deleting disks but allow them to create them → Use a Predefined Role or Custom Role.
Exam Tips: ACE Golden Nuggets
- Inheritance is Top-Down: If you are an “Owner” at the Project level, you are an “Owner” of every resource inside it. You cannot “take away” a permission at a lower level if it was granted at a higher level.
- Service Accounts are Resources: A service account is both an identity (it acts as a principal) and a resource (you can grant users permission to “use” it).
- Avoid Primitive Roles: On the exam, if an answer suggests giving “Editor” access to a developer who only needs to manage Pub/Sub, it’s likely the wrong answer. Look for the Predefined role.
- Policy Troubleshooting: Use the IAM Policy Troubleshooter to figure out why a user can’t access a resource.
IAM Architecture Visualized
Permissions flow down through the hierarchy via inheritance.
Key GCP Services
- Cloud IAM: Policy management.
- Cloud Identity: Managed users/groups.
- Service Accounts: Machine-to-machine auth.
Common Pitfalls
- Granting Owner to service accounts.
- Not using Groups for user management.
- Leaving Service Account Keys in code.
Quick Patterns
- Least Privilege: Start with nothing.
- Audit Logs: Track who did what.
- IAM Conditions: Access based on time/IP.