Back to all blogs
    8 min read

    06 - IAM & Access Management - Users, Roles, Service Accounts

    gcpcloudsecurityiam

    Welcome to Day 06 of Learn GCP in 30 Days! Today, we explore the core foundation of Google Cloud security: Identity & Access Management (IAM).

    🎯

    Today's Goal Yesterday, you set up your budget safety net. Today, you will learn how Google Cloud keeps your project safe using IAM (Identity & Access Management)—learning how to give people and apps the exact permissions they need without giving away master keys!

    The Core Problem: Who Gets Access to What?

    Imagine a growing company with 50 employees (senior developers, intern developers, financial accountants, and automated background apps).

    If everyone is given master admin access to the cloud:

    • An intern might accidentally delete the main production database!
    • An external contractor might view private company financial files.
    • A hacker who steals a junior team member's password could wipe out the entire company server setup.

    How IAM Solves This Problem

    IAM (Identity & Access Management) is Google Cloud's digital security guard. It ensures that every person and every automated application gets only the exact access keys they need to do their job—nothing more.

    GCP's security guard checks 3 simple questions for every action:

    1. 👤 WHO is asking? (A human developer or an automated app bot?)
    2. 🔑 WHAT are they allowed to do? (Read files, deploy code, or restart servers?)
    3. ⚙️ WHICH specific resource can they touch? (Just 1 file bucket, or 1 specific server?)
    mermaid
    

    

    Detailed Breakdown of IAM Building Blocks
    

    Let's look at the 3 building blocks of IAM:
    

    1. Identity (WHO is requesting access?)
    

    An Identity is simply the user or bot asking to perform an action:
    

      

    • 👤 Google Account: An individual human user logging in with their email address (alex@gmail.com).
      • 

    • 👥 Google Group: A group of team members (developers@company.com). Granting access to a group automatically grants it to all members.
      • 

    • 🤖 Service Account: A special non-human bot account used by applications, code, and virtual servers to talk to other GCP services automatically.
      • 

    

    

    2. Roles (WHAT can they do?)
    

    A Role is a bundle of permissions. Instead of manually giving someone 50 individual permission keys one-by-one, you give them 1 Role.
    

    GCP provides 3 Types of Roles:
    

    mermaid
    

    Type 1: Primitive Roles (Legacy — Avoid in Production!)
    

      

    • Owner: Full control over all resources + ability to manage billing and add/remove users.
      • 

    • Editor: Create, modify, and delete all resources across the entire project.
      • 

    • Viewer: Read-only access to all resources across the entire project.
      • 

    

    ⚠️
    

    Why Primitive Roles Are Dangerous
Primitive roles give blanket access. Giving a team member the Editor role allows them to delete every database, file bucket, and server in your project! Always avoid Primitive roles in production.
    

    

    Type 2: Predefined Roles (Recommended by Google)
    

      

    • What they are: Specific, fine-grained roles created and maintained automatically by Google.
      • 

    • Examples:

        

      • Storage Object Viewer (Can read files in Cloud Storage, but cannot delete buckets or touch servers).
        • 

      • Compute Instance Admin (Can create and restart servers, but cannot touch databases).
        • 

      

      • 

    • Best Practice: Always use Predefined Roles for real-world projects!
      • 

    

    Type 3: Custom Roles (Advanced)
    

      

    • What they are: Custom-built roles created by security teams when no Predefined Role fits an exact company policy.
      • 

    

    

    3. Service Accounts (Non-Human Bot Accounts)
    

    Imagine you build a Python web app running inside a virtual server (VM). Your Python app needs to upload user photos to a Cloud Storage bucket every 5 seconds.
    

      

    • Why Hardcoding Human Passwords is Bad: If a developer hardcodes their personal password or private key inside application code and pushes that code to GitHub, anyone on the internet can read their password and delete the company's servers! Furthermore, when that developer leaves the company and their personal account is deleted, the app crashes!
      • 

    

    💡
    

    How Service Accounts Solve This
When you create a Service Account, GCP generates a dedicated, secure digital credential token that connects your website or mobile app directly to GCP. Your app uses these credentials automatically—no human passwords or personal logins are ever written inside your code!
    

    

      

    • How to Use a Service Account:

        

      1. You create a Service Account (e.g., photo-uploader-bot@my-project.iam.gserviceaccount.com).
        2. 

      2. You grant that Service Account the Storage Object Creator role.
        3. 

      3. You attach the Service Account to the virtual server.
        4. 

      4. Now, the server connects to GCP automatically in the background using secure bot credentials.
        5. 

      

      • 

    

    mermaid
    

    

    4. The Principle of Least Privilege
    

    The golden rule of cloud security is the Principle of Least Privilege:
    

    🛡️
    

    Principle of Least Privilege
Always grant only the minimum permissions necessary for a person or bot to perform their specific job—nothing more!
    

    

      

    • If a team member only needs to view logs, grant Logging Viewer—do NOT grant Editor or Owner.
      • 

    • If a background script only needs to save files, grant Storage Object Creator—do NOT grant Storage Admin.
      • 

    

    

    Signal vs. Noise: What to Remember vs. What to Ignore
    

    🧠
    

    Must Remember
    

      

    • 3 IAM Questions: WHO (Identity) + WHAT (Role) + WHICH RESOURCE.
      • 

    • Service Accounts: Special non-human bot accounts used by code, apps, and virtual servers.
      • 

    • Avoid Primitive Roles: Do not use Owner or Editor in production—use Predefined Roles (e.g. Storage Object Viewer).
      • 

    • Principle of Least Privilege: Grant only the minimum required permissions.
      • 

    

    

    ℹ️
    

    Noise Filter (Don't Memorize)
    

      

    • Do NOT try to memorize 1,000+ individual permission names (like compute.instances.start or storage.buckets.get). You simply select Predefined Roles from dropdown menus in the GCP Console.
      • 

    • Do NOT worry about creating Service Account JSON keys manually—GCP handles automatic short-lived token authentication natively when service accounts are attached to resources.
      • 

    

    

    

    Common Doubts & Interview Traps
    

    Q1: Why should I avoid giving team members the "Editor" Primitive Role in a production project?
    

      

    • Answer: The Editor role gives blanket permission to modify or delete all resources across the entire project (VMs, databases, networks, buckets). If a developer's credentials are compromised or an error occurs, the entire project infrastructure can be wiped out. Use fine-grained Predefined Roles instead.
      • 

    

    Q2: Can a Service Account act as both an Identity AND a Resource?
    

      

    • Answer: Yes! Think of a Service Account like a Company Car:

        

      • As an Identity (The Driver): When the Service Account bot goes to Cloud Storage to upload a file, it acts as an Identity showing its ID card to gain access.
        • 

      • As a Resource (The Car): When an admin wants to give a developer permission to "drive" or use that Service Account bot to deploy code, the Service Account itself is treated as a Resource (e.g. granting the Service Account User role).
        • 

      

      • 

    

    

    Daily Practice Drill & Self-Check
    

    Test your understanding of today's lesson:
    

    text
    // Try answering these:
1. A junior data analyst needs to read reports stored inside a Cloud Storage bucket, but must never be allowed to delete files or touch virtual servers. Which role type should you assign to them?
2. A Python script running on a Linux VM needs to query a Cloud SQL database automatically. Should you log the VM in using a developer's personal Google Account or a Service Account?

    

    💡 Click for Solutions

      

    1. Assign them a Predefined Role such as Storage Object Viewer! This gives them read-only access to storage objects without granting delete or server permissions.
      2. 

    2. Use a Service Account! Service Accounts are designed specifically for non-human applications and code running on VMs, eliminating the need to hardcode human credentials.
      3. 

    

    

    

    🎉 Awesome job! You have completed Day 06.
    

    You now understand IAM security, identities, the 3 role types, Service Accounts, and the Principle of Least Privilege. Take a break, let today's concepts sink in, and come back tomorrow fresh!
    

    Tomorrow on Day 07, we will complete Week 1 with a Hands-on Lab: Setting Up Your First GCP Project & Cloud Shell CLI where you will run your first real gcloud commands!
    

    

    ← 05 - GCP Billing & Setting Up Your $300 Free Credit | Next Topic → 07 - Hands-on Lab - Setting Up Your First GCP Project & Cloud Shell