Skip to main content
Google Cloud Platform (GCP)
CHAPTER 03

Identity and Access Management (IAM)

Updated: May 15, 2026
20 min read

# CHAPTER 3

Identity and Access Management (IAM)

1. Introduction

Security in the cloud does not start with firewalls; it starts with Identity. If a malicious actor gains access to an administrator's credentials, firewalls are useless because the attacker simply turns them off. Identity and Access Management (IAM) is the central nervous system of GCP security. It dictates *Who* can do *What* on *Which* resource. In this chapter, we will master the Principle of Least Privilege, explore the relationship between Members and Roles, and introduce Service Accounts.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Define the three pillars of IAM: Principals, Roles, and Policies.
  • Differentiate between Basic, Predefined, and Custom roles.
  • Understand and enforce the Principle of Least Privilege.
  • Define what a Service Account is and why it is critical for automation.
  • Assign IAM permissions within the GCP Console.

3. Beginner-Friendly Explanation

Imagine a high-security office building.
  • The Principal (Who): The employee holding an ID badge (e.g., alice@company.com).
  • The Role (What): A title stamped on the badge, like "Janitor" or "CEO".
  • The Policy (Which Resource): The building's rulebook. It says: "People with the Janitor role are allowed to open the Supply Closet. They are NOT allowed to open the Server Room."

In GCP, you never give permission directly to a person. You give a person a Role. The Role contains the permissions.

4. The Three Types of Roles

When assigning permissions, you have three categories of Roles:
  1. 1. Basic Roles (Avoid these): The original, legacy roles (Viewer, Editor, Owner). They are dangerously broad. If you make someone an Editor, they can edit *everything* in the entire project.
  1. 2. Predefined Roles (Use these): Created and maintained by Google. They are highly specific. Example: Compute Instance Admin (Can create/delete Virtual Machines, but cannot touch databases).
  1. 3. Custom Roles: You create these yourself by hand-picking exact API permissions (e.g., "Can view VMs, but cannot delete them"). Used only when Predefined roles don't perfectly fit.

5. Service Accounts (Software Identity)

Humans use Gmail addresses (user@gmail.com) to log in. But what if a Python script running on a server needs to upload a file to Cloud Storage? A script cannot type in a password or complete 2-Factor Authentication!

A Service Account is a special email address (e.g., my-app@my-project.iam.gserviceaccount.com) created exclusively for software. You give the Service Account a Role (e.g., Storage Object Creator), attach the account to your Virtual Machine, and the Python script inherits those permissions automatically, with no passwords required!

6. The Principle of Least Privilege

The golden rule of Cloud Security: Give a user the exact minimum permissions they need to do their job, and absolutely nothing more. If a junior developer only needs to view logs to debug an app, give them the Logs Viewer role. Do not give them the Editor role just because it's faster to assign. If their laptop is hacked, Least Privilege prevents the hacker from destroying the database.

7. Mini Project: Assign Secure IAM Roles

Let's practice granting restricted access.

Step-by-Step Tutorial:

  1. 1. Open the GCP Console and navigate to IAM & Admin > IAM.
  1. 2. Click the + GRANT ACCESS button at the top.
  1. 3. In the New principals box, type the email address of a friend or a secondary Google account you own.
  1. 4. In the Select a role dropdown, do NOT choose a Basic role. Instead, search for and select Compute Network Viewer.
  1. 5. Click Save.
  1. 6. *The Result:* That user can now log into your GCP project. They can look at your VPC networks and IP addresses, but if they try to look at your Virtual Machines or Databases, the console will present them with a massive "PERMISSION DENIED" error. Security in action!

8. Real-World Scenarios

A company hired a freelance web developer to upload HTML files to a Cloud Storage bucket. The lazy IT admin gave the freelancer the Project Editor role. The freelancer's email account was breached by a hacker. Because the hacker had Editor access, they bypassed the storage bucket entirely, spun up 50 massive Virtual Machines in the project, and started mining Bitcoin, costing the company $20,000 in 48 hours. Had the admin used Least Privilege and assigned the Storage Object Creator role, the hacker could only have uploaded files, preventing the Bitcoin mining disaster.

9. Best Practices

  • IAM Conditions: You can attach time-based conditions to Roles. If a contractor needs access to a database to perform a weekend migration, use IAM Conditions to grant them the Database Admin role, but explicitly set it to automatically expire on Monday morning at 8:00 AM.

10. Security Tips

  • Never Download Service Account Keys: While GCP allows you to download Service Account credentials as a physical JSON file to your laptop, you should avoid this at all costs. If you accidentally commit that JSON file to GitHub, hackers will find it in seconds. Always use native IAM binding or Workload Identity Federation instead of downloading keys.

11. CLI Examples

To view the IAM policy of your current project (who has access to what):
bash
1 
gcloud projects get-iam-policy my-first-gcp-project

To create a new Service Account via CLI:

bash
123 
gcloud iam service-accounts create my-robot-account \
    --description="Used by the Python API" \
    --display-name="Python API Service Account"

12. Exercises

  1. 1. Explain why assigning the Basic Editor role violates the Principle of Least Privilege.
  1. 2. What is the fundamental difference between a User Account and a Service Account?

13. FAQs

Q: I gave a user permission, but they still can't see the resource. Why? A: IAM permissions can take 60 to 120 seconds to propagate globally across Google's servers. Tell the user to wait two minutes and hard-refresh their browser.

14. Interview Questions

  • Q: Define the Principle of Least Privilege. Provide a specific scenario demonstrating how violating this principle within GCP IAM could lead to a catastrophic data breach.
  • Q: Explain the architectural security benefits of attaching a Service Account directly to a Compute Engine instance, rather than embedding long-lived Service Account JSON keys within application source code.

15. Summary

In Chapter 3, we locked down our cloud environment. We established that IAM is the foundation of GCP security, functioning by connecting Principals to specific Roles. We rejected the dangerously broad Basic roles in favor of precise Predefined roles, adhering strictly to the Principle of Least Privilege. Finally, we introduced Service Accounts as the secure, keyless identity mechanism required for automated software and servers to interact with GCP APIs.

16. Next Chapter Recommendation

Our project is secure and our billing is monitored. It is finally time to build something. Proceed to Chapter 4: Compute Engine Virtual Machines.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Google Cloud Free Tier and Billing Basics
Next Chapter Compute Engine Virtual Machines

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 5

❓ Related Quizzes 6