IAM Fundamentals & Roles

Introduction to Google Cloud IAM

GCP IAM (Identity and Access Management) is the security heart of Google Cloud. It allows administrators to authorize who can take action on specific resources, giving you full control and visibility to manage Google Cloud resources centrally. For the Associate Cloud Engineer (ACE) exam, GCP IAM is one of the most heavily tested domains because it touches every single service in the cloud.

Without a solid grasp of GCP IAM, you cannot safely deploy virtual machines, manage databases, or even look at billing data. GCP IAM provides a unified interface for access control across all Google Cloud services. By using GCP IAM, you can ensure that your organization follows the principle of least privilege, minimizing the risk of data breaches and accidental resource deletion.

白話文解釋（Plain English Explanation）

To make the abstract concepts of GCP IAM more concrete, let's use three analogies that describe how identity, roles, and permissions work together.

1. The Secure Office Building (Access Cards)

Imagine a high-security office building:

• The Identity (Member) is the Employee.
• The Permission is the ability to "Open Door A" or "Use the Elevator."
• The Role is a pre-programmed Access Card labeled "Maintenance" or "Executive."
• The Resource is the Server Room or the CEO's Office.

Instead of giving every employee a list of 50 doors they can open, the building manager creates a "Maintenance Access Card" (Role) that includes all the necessary door permissions. When a new maintenance worker (Member) joins, they are simply handed that card. This is exactly how GCP IAM groups permissions into roles to simplify management.

2. The Library System (User Privileges)

Think about how a public library operates:

• The Identity is the Library Card Holder.
• The Resource is the collection of Books and Media.
• The Permission is the specific action, like "Check Out Book," "Return Book," or "Delete Catalog Entry."
• The Role is the job title, like "Patron," "Librarian," or "Director."

A "Patron" role in this GCP IAM analogy allows checking out books but not deleting the catalog. A "Librarian" has more permissions, such as adding new books. The "Director" has full control. You assign the role to the person, which determines what they can do with the library's resources.

3. The Restaurant (Service Roles)

Consider the staff at a busy restaurant:

• The Identity is a Staff Member (e.g., John).
• The Resource is the Kitchen, the Dining Room, and the Cash Register.
• The Role is the position, like "Chef," "Waiter," or "Manager."
• The Permission is a task, like "Cook Food," "Take Order," or "Issue Refund."

In this GCP IAM scenario, John is assigned the "Waiter" role. This role contains a bundle of permissions: taking orders and serving food. John cannot "Cook Food" because that permission is not in the Waiter role. If John is promoted to Manager, his role is changed, and his permissions are automatically updated.

The Three Pillars of IAM: Who, What, on Which

The GCP IAM policy follows a simple sentence structure: Who (Identity) can do What (Role) on Which resource.

The "Who": Members and Identities

In GCP IAM, a "member" is the identity being granted access. This could be a human (using a Google Account), a group of people (Google Group), or a non-human entity like an application (Service Account).

The "What": Roles and Permissions

A "permission" is the granular ability to perform an action (e.g., compute.instances.start). In GCP IAM, you do not grant permissions directly to users. Instead, you grant a "role," which is a collection of one or more permissions.

The "Which": Resources

Resources are the GCP entities themselves—Projects, Compute Engine instances, Cloud Storage buckets, etc. GCP IAM allows you to grant access at different levels of the resource hierarchy.

Types of IAM Members

There are several types of identities you will encounter in GCP IAM:

Google Accounts

Individual users with an @gmail.com address or a custom domain managed by Google.

Service Accounts

An account for an application or a virtual machine, rather than an individual person. Service accounts are a critical part of GCP IAM for automated tasks.

Google Groups

A collection of Google Accounts and Service Accounts. Assigning a role to a group in GCP IAM is a best practice for managing permissions at scale.

Google Workspace and Cloud Identity Domains

Represent a virtual group of all the Google Accounts that have been created in an organization's domain.

Understanding IAM Roles

GCP IAM offers three categories of roles, each with varying levels of granularity.

Primitive Roles: Owner, Editor, Viewer

These are the legacy roles that existed before the full GCP IAM system was developed.

• Viewer: Read-only access.
• Editor: All viewer permissions plus the ability to modify resources.
• Owner: All editor permissions plus the ability to manage roles and billing.

Predefined Roles: The Recommended Standard

These roles are created and maintained by Google. They provide granular access to specific services (e.g., roles/storage.objectAdmin). Using predefined roles is the "Gold Standard" for GCP IAM management.

Custom Roles: Tailored Permissions

If predefined roles don't meet your needs, you can create a Custom Role. However, custom roles in GCP IAM require manual maintenance as Google adds new permissions to services.

IAM Policy Structure

An IAM Policy is a collection of bindings that associate members with roles.

Policy Bindings

A binding consists of a list of members and the role being granted to them. In the GCP IAM backend, this is represented as a JSON or YAML file.

Condition-Based Access

GCP IAM Conditions allow you to grant access based on attributes like time, resource name, or IP address. For example, you could grant "Editor" access only during business hours.

Audit Logging for Policies

Every change to a GCP IAM policy is logged in Cloud Audit Logs. This provides an audit trail for compliance and security troubleshooting.

The Principle of Least Privilege

The Principle of Least Privilege (PoLP) is the foundation of secure GCP IAM design.

Why it Matters for ACE

As an Associate Cloud Engineer, you are responsible for ensuring that users have only the permissions they need to do their jobs—and nothing more. This minimizes the "blast radius" of a compromised account.

Implementing Minimal Access

Instead of giving a developer the "Editor" role, give them specific predefined roles like "Compute Instance Admin" and "Storage Object Creator" within the GCP IAM framework.

Using the IAM Recommender

Google Cloud provides an IAM Recommender that analyzes your GCP IAM usage and suggests more restrictive roles if a user is not utilizing all their granted permissions.

IAM Inheritance and the Hierarchy

Permissions in GCP IAM are inherited from parent to child resources.

Propagation of Permissions

If you grant a role at the Organization level, it flows down through all Folders, Projects, and Resources. You cannot revoke an inherited permission in GCP IAM.

Effective Policy Calculation

A member's "effective policy" is the union of all roles granted at every level of the hierarchy. GCP IAM is additive.

Deny Policies (The Exception to Additive IAM)

While standard GCP IAM is additive, "Deny Policies" allow you to explicitly forbid certain actions regardless of what roles are granted. Deny policies always take precedence.

Managing Service Accounts

Service accounts are unique because they act as the "identity" for your code and infrastructure.

Service Account Keys vs. IAM Impersonation

While you can download JSON keys for service accounts, GCP IAM best practices suggest using "Service Account Impersonation" or "Workload Identity" to avoid the risk of leaked keys.

Service Account as a Resource vs. as an Identity

You can grant a user the roles/iam.serviceAccountUser role. This allows them to "act as" the service account, which is a powerful and essential part of GCP IAM automation.

Default Service Accounts

Some services (like Compute Engine) come with default service accounts. These often have broad "Editor" permissions by default, which should be restricted for production use.

Using the gcloud CLI for IAM

Mastering the CLI is a requirement for the ACE exam.

gcloud projects add-iam-policy-binding

This is the most common command for granting access:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:[email protected]" \
    --role="roles/viewer"

gcloud iam roles describe

Use this command to see the specific permissions included in a GCP IAM role.

Listing and Testing Permissions

You can list all members of a project using gcloud projects get-iam-policy.

Advanced IAM Concepts

Identity-Aware Proxy (IAP)

IAP uses GCP IAM to control access to your web applications and VMs without needing a VPN. It verifies the user's identity before allowing the connection.

Workload Identity

This is the recommended way for applications running on GKE to authenticate to Google Cloud services using GCP IAM without managing secret keys.

Resource Quotas and IAM

The ability to view or request increases for resource quotas is controlled by specific GCP IAM roles (roles/servicemanagement.quotaViewer).

Security Best Practices for IAM

1. Use Groups, Not Individuals: Assign roles to Google Groups to make member management easier.
2. Prefer Predefined Roles: Avoid primitive roles (Owner/Editor/Viewer) in production.
3. Audit Regularly: Use the Policy Analyzer to find who has access to what.
4. Use Conditions: Add an extra layer of security with time-based or IP-based access.

Troubleshooting IAM Access Issues

Policy Troubleshooter Tool

If a user is getting "Permission Denied," use the Policy Troubleshooter in the Cloud Console to determine which policy is causing the block.

IAM Policy Analyzer

This tool helps you answer complex questions like "Which users have access to this specific service account from outside my organization?"

Common "Permission Denied" Errors

Usually caused by:

• Role granted at the wrong level of the hierarchy.
• Propagation delay (though IAM changes are usually fast).
• The user is logged into the wrong Google account.

Common Exam Scenarios for ACE

Assigning Roles to a Team

"Your development team needs to manage GKE clusters but should not be able to delete the project. What role should you give them?" (Answer: roles/container.admin).

Creating a Custom Role

"A user needs only one specific permission that isn't in any predefined role. What should you do?" (Answer: Create a Custom Role at the project level).

Troubleshooting a Denied Request

"A developer says they cannot start a VM, even though you gave them the Compute Viewer role. Why?" (Answer: Viewer doesn't have the compute.instances.start permission).

FAQ

Q1: Can I revoke a permission that was inherited from a parent folder? A1: No. GCP IAM is additive. To restrict access, you must move the resource or change the role at the parent level.

Q2: What is the maximum number of custom roles I can create? A2: You can create up to 300 custom roles per project and 100 per organization.

Q3: Is there a difference between a Google Account and a Service Account? A3: Yes. Google Accounts represent humans; Service Accounts represent applications or VMs. Both are "members" in GCP IAM.

Q4: Can I add a non-Google email address to an IAM policy? A4: Only if that email is associated with a Google Account or is part of a Cloud Identity/Workspace domain.

Q5: What happens if I delete a Service Account that was assigned a role? A5: The role binding remains in the policy as a "deleted" principal. It's best practice to clean up these "ghost" entries.

Summary Checklist for ACE

• Understand the difference between Primitive, Predefined, and Custom roles.
• Memorize the key CLI commands for GCP IAM policy bindings.
• Know how to use Service Accounts for application-to-service authentication.
• Be able to explain why Google Groups are better than individual user assignments.
• Understand how inheritance works across the Resource Hierarchy.
• Recognize the importance of the Principle of Least Privilege.