Access Control: IAM & ACLs
In Google Cloud, access control is the mechanism that ensures only the right identities have the necessary permissions to interact with your resources. For the ACE exam, understanding the hierarchy of these permissions and the distinction between IAM and legacy ACLs is critical for security and operational excellence.
The Analogy: The Corporate Office Building
Imagine a high-security office building:
- IAM (Identity & Access Management): This is your Employee Badge. Your badge says you are part of the “Marketing Team” (Role) and allows you to enter the building, use the elevators, and access the Marketing Floor (Resources). It is centrally managed and applies to everyone in your department.
- ACLs (Access Control Lists): This is a Physical Key to a specific desk drawer. It doesn’t care what department you are in; if you have the key, you can open that specific drawer. It’s granular but hard to manage if you have 10,000 drawers.
Detail Elaboration: The IAM Policy Triangle
IAM is defined by a policy that binds three elements together:
- Who (Identity): A Google Account, Service Account, Google Group, or Cloud Identity Domain.
- What (Role): A collection of permissions (e.g.,
storage.buckets.get). - Where (Resource): The specific resource (Project, Bucket, Instance) the policy is applied to.
Core Concepts & Best Practices
- Resource Hierarchy: Permissions flow downward. Organization > Folder > Project > Resource. If you are an Editor at the Project level, you are an Editor for every bucket inside it. You cannot take away a permission inherited from a higher level.
- Least Privilege: Always grant the minimum permission required. Use Predefined Roles (like Storage Object Viewer) instead of Primitive Roles (Owner, Editor, Viewer).
- Service Accounts: These are identities used by applications/workloads, not humans. For the ACE exam, remember that Service Accounts are both an Identity and a Resource.
Comparison: IAM vs. ACLs
| Feature | Cloud IAM | Access Control Lists (ACLs) |
|---|---|---|
| Scope | Project, Bucket, or Folder level. | Individual Object (file) level. |
| Management | Centralized and scalable. | Decentralized and granular. |
| Best Use Case | Standardizing access for teams. | Granting access to one specific file in a bucket. |
| ACE Recommendation | Primary choice for all scenarios. | Legacy; use only if IAM isn’t granular enough. |
Decision Matrix: Scenario-Based Learning
| If the requirement is… | Use this Service/Feature… |
|---|---|
| Granting a developer access to all Compute Engine instances. | IAM Predefined Role (Compute Admin) at Project level. |
| Allowing a GKE pod to write to a Cloud Storage bucket. | Service Account with Storage Object Creator role. |
| Sharing a single 10GB log file with an external auditor. | ACL (Object level) or Signed URL. |
| Restricting access to certain regions for all projects. | Organization Policy Service. |
Exam Tips: ACE Golden Nuggets
- Inheritance is Additive: You cannot “deny” a permission at a lower level if it was granted at a higher level.
- Primitive Roles are Dangerous: Avoid “Owner”, “Editor”, and “Viewer” in exam answers unless specifically asked for broad access.
- Groups over Individuals: It is always a best practice to assign roles to Google Groups rather than individual email addresses.
- Service Account Keys: GCP manages “Google-managed keys” automatically. “User-managed keys” are your responsibility and a security risk if not rotated.
GCP IAM Architecture Flow
Key GCP Services
- Cloud IAM: Centralized authorization.
- Identity Platform: Add Auth to your apps.
- Policy Troubleshooter: Debug “Why is access denied?”
- IAM Recommender: Suggests removing unused roles.
Common Pitfalls
- Granting Owner role to a Service Account.
- Deleting a Project without checking IAM dependencies.
- Confusing Authentication (Who are you?) with Authorization (What can you do?).
Quick Patterns
- Dev Access: Group-based IAM roles.
- App Access: Service Account + Workload Identity.
- External Access: Signed URLs or Cloud Identity.