Identity and Access Management (IAM)

Introduction to IAM on Google Cloud

For a Professional Cloud Architect, IAM is the most critical security boundary. It answers the fundamental question: "Who can do what on which resource?" A well-architected IAM strategy follows the Principle of Least Privilege, ensuring that every identity has exactly the permissions it needs—and no more.

Plain-Language Explanation: IAM

IAM is like the security system of a high-security research facility.

Analogy 1 — The Security Badge (Identity)

In a facility, everyone has a Security Badge. This badge doesn't just say your name; it tells the system who you are—a researcher, a janitor, or a visitor. In GCP, your Identity is your email address (Google Workspace, Cloud Identity, or a Service Account).

Analogy 2 — The Job Title (Role)

A "Security Guard" role comes with a set of keys. You don't give a guard individual keys for "Front Door," "Back Door," and "Warehouse." You just give them the Security Guard Role, which automatically includes all those keys. In GCP, Roles are collections of permissions. You assign roles to identities, not individual permissions.

Analogy 3 — The Keycard Reader (Policy)

The IAM Policy is the logic inside the Keycard Reader on the door. When you tap your badge, the reader asks: "Does this specific badge (Identity) have the 'Science Lab Access' (Role) for this specific door (Resource)?" If the answer is yes, the door opens.

The IAM Model: Who, Can Do What, on Which

The IAM policy is a mapping of Members to Roles at a specific Resource level.

1. The "Who" (Identities)

• Google Accounts: Individual users (e.g., [email protected]).
• Service Accounts: Identities for applications and workloads (e.g., [email protected]).
• Google Groups: The recommended way to manage users. Assign roles to a group, and then add/remove users from that group.
• Google Workspace/Cloud Identity Domains: All users in an organization.

2. The "Can Do What" (Roles)

• Primitive Roles: (Owner, Editor, Viewer). Avoid using these in production as they are too broad.
• Predefined Roles: Managed by Google (e.g., roles/storage.objectViewer). Granular and updated automatically.
• Custom Roles: Created by you for specific needs. Use these when predefined roles are still too broad.

3. The "Which" (Resources)

IAM roles can be applied at different levels of the Resource Hierarchy:

• Organization (Top level)
• Folder
• Project
• Resource (e.g., a specific GCS bucket or Cloud SQL instance)

Service Accounts (Application Identities)

Service accounts are the backbone of GCP security for workloads.

• No Passwords: They use cryptographic keys (managed by Google or manually).
• Service Account ActAs: A user must have the roles/iam.serviceAccountUser role to "impersonate" or use a service account.
• Short-lived Credentials: Use these instead of static JSON keys whenever possible to reduce the risk of leaked credentials.

Workload Identity (GKE & Multi-cloud)

Workload Identity is the secure way for applications running on Kubernetes (GKE) or other clouds to access GCP services.

• The Old Way: Export a JSON key and mount it as a secret (Dangerous!).
• The New Way: Link a Kubernetes Service Account (KSA) to a Google Service Account (GSA). GKE automatically handles the token exchange. No keys to manage!

Conditional IAM

You can add Conditions to IAM bindings to make them even more granular.

• Time-based: "Allow access only between 9 AM and 5 PM."
• Resource-based: "Allow access only to buckets starting with the prefix public-."
• IP-based: "Allow access only from the corporate VPN IP address."

IAM Best Practices for Architects

1. Use Groups: Never assign roles to individual users. It's a management nightmare.
2. Principle of Least Privilege: Use the most granular role possible. Use IAM Recommender to find and remove unused permissions.
3. Audit Everything: Enable Cloud Audit Logs (Data Access logs) to see who did what.
4. Rotate Keys: If you must use service account keys, rotate them every 90 days.
5. Use Workload Identity Federation: For resources outside of Google Cloud (e.g., AWS, Azure, or on-prem) to access GCP without service account keys.

FAQ — Identity and Access Management

Q1. What is the difference between a Predefined Role and a Custom Role?

Predefined Roles are managed by Google and updated automatically when new features are added. Custom Roles are managed by you and offer the most granular control, but you are responsible for updating them if a service's underlying permissions change.

Q2. Should I use a Service Account Key?

Avoid them if possible. Service account keys are "long-lived" and can be leaked. Prefer Workload Identity, Identity Federation, or Service Account Impersonation.

Q3. Can I deny a permission in IAM?

IAM is additive only. You grant permissions; you don't "deny" them. If a user has "Editor" at the project level, you cannot "deny" them access to a specific bucket in that project. Organization Policies, however, can be used to restrict actions.

Q4. What does the "IAM Recommender" do?

It uses machine learning to analyze your IAM logs and suggests removing permissions that haven't been used in the last 90 days, helping you achieve Least Privilege.

Q5. How do I manage access for a 3rd party contractor?

Add them to a specific Google Group in your organization and assign the necessary roles to that group. When their contract ends, simply remove them from the group.

Final Architect Tip

For the PCA exam, the answer to "How to secure an application?" is almost always Workload Identity (for GKE) or Service Account with Least Privilege. Remember that Groups are for people and Service Accounts are for machines. If a question mentions "reducing administrative overhead," the answer is Google Groups. If it mentions "regulatory compliance for auditing," the answer is Cloud Audit Logs.