Lab 02 GCP IAM Security

Identity is one of the most important security boundaries in Google Cloud.

A weak firewall can expose a workload.

A weak IAM configuration can expose the entire cloud environment.

In this lab, you will assess Google Cloud Identity and Access Management from the perspective of a Cloud Security Engineer.

You will review:

Users
Groups
Service accounts
Roles
Permissions
IAM policies
Policy inheritance
Privileged identities
Excessive access
Least privilege

Mission Goal: Assess IAM access inside an authorized Google Cloud project, identify risky permissions, and recommend least-privilege remediation.

Mission Information

Difficulty: Beginner to Intermediate
Estimated Time: 60–90 minutes
Primary Skill: Google Cloud IAM Security Assessment
Platform: Google Cloud
Career Alignment: Cloud Security Engineer, IAM Engineer, Security Consultant, Cloud Security Analyst

What You Will Learn

By completing this lab, you will learn how to:

Review IAM principals
Understand role assignments
Identify broad permissions
Review basic, predefined, and custom roles
Analyze service account privileges
Understand IAM inheritance
Identify privileged access
Assess least privilege
Document IAM findings
Build a repeatable IAM review process

Why This Lab Matters

Google Cloud IAM determines:

Who
Can Do What
On Which Resource

The basic relationship is:

Principal
   ↓
Role
   ↓
Permissions
   ↓
Resource

If any part of this relationship is too broad, risk increases.

For example:

Developer
   ↓
Owner Role
   ↓
Production Project

This may allow far more access than required.

Lab Scenario

You are working as a Google Cloud Security Engineer.

Your organization has asked you to review IAM configuration for a cloud project before it is approved for production use.

The environment contains:

Human users
Groups
Service accounts
Administrative roles
Application identities
Project-level permissions

Your task is to determine whether access follows the principle of least privilege.

Lab Architecture

Google Cloud Project
        │
        ├── Users
        ├── Groups
        ├── Service Accounts
        │
        ├── IAM Roles
        │
        └── Cloud Resources
                 ↓
            Security Review

Prerequisites

Before starting, make sure you have:

Access to an authorized Google Cloud lab project
Permission to view IAM configuration
Permission to create temporary lab identities or assignments where appropriate
Basic familiarity with Google Cloud Console
Completed the Cloud Logging lab or understand Cloud Audit Logs

Lab Safety

Perform this exercise only in an authorized lab environment.

Do not:

Change production IAM
Remove legitimate administrative access
Grant unnecessary privileged roles
Create long-lived credentials unnecessarily
Modify organization-level access without authorization

This lab focuses on secure assessment and controlled remediation.

Part 1 — Open IAM

Confirm that the correct lab project is selected.

Navigate to:

IAM & Admin
    ↓
IAM

Review the IAM page.

You should see principals and their assigned roles.

Depending on the environment, principals may include:

Users
Groups
Service accounts
Google-managed identities

Your First Security Question

Do not immediately change anything.

Start by asking:

Who currently has access to this project?

This is the first question in almost every IAM assessment.

Part 2 — Inventory the Principals

Create an inventory of the identities visible in the project.

Your table may look like:

Principal	Type	Role	Expected?	Review Required?
user@example.com	User	Viewer	Yes	No
admins@example.com	Group	Admin Role	Yes	Yes
app-sa	Service Account	Service Role	Yes	Yes

Do not assume a role is safe just because the principal is known.

You must still validate whether the access is appropriate.

Part 3 — Classify Principal Types

For each principal, determine whether it represents:

Human User
Group
Service Account
Workload Identity
Managed Service Identity

Identity type matters because access patterns differ.

For example:

Human Administrator

may reasonably have interactive access.

But:

Application Service Account

should generally have only workload-specific permissions.

Part 4 — Understand IAM Roles

Google Cloud roles contain permissions.

There are three major categories you should understand.

Basic Roles

Examples include:

Owner
Editor
Viewer

These roles are broad.

Owner

Can provide extensive administrative capabilities.

Editor

Can modify many resources.

Viewer

Primarily provides read access.

Basic roles should receive careful review in production environments.

Predefined Roles

Predefined roles are managed by Google and designed for specific services.

Examples may include roles for:

Storage
Compute
Logging
Monitoring
IAM
Security

These generally allow more precise access than broad basic roles.

Custom Roles

Organizations can define custom roles containing selected permissions.

Custom roles may be appropriate when predefined roles do not fit a requirement.

However, they create additional governance responsibilities.

Part 5 — Identify Broad Roles

Review the project for identities assigned:

Owner
Editor

Do not immediately assume every assignment is wrong.

Instead ask:

Who has the role?
        ↓
Why do they need it?
        ↓
What tasks do they perform?
        ↓
Could a narrower role work?

This is the core of least-privilege analysis.

Finding Example

Suppose you identify:

Principal:
developer@example.com

Role:
Editor

Scope:
Entire Project

Ask:

Does this developer really need modification rights across the entire project?

If not, this may be an excessive privilege finding.

Part 6 — Review Owner Access

Owner-level access deserves special attention.

Create an inventory:

Project Owners
      ↓
Human?
Group?
Service Account?
Expected?
Documented?

A service account with broad ownership privileges should receive immediate scrutiny.

Security Perspective

Highly privileged roles can allow actions such as:

Resource modification
IAM changes
Service account management
Infrastructure creation
Security control modification

The greater the privilege, the greater the impact of compromise.

Part 7 — Review Group-Based Access

Check whether human access is assigned:

Directly to Users

or:

Through Groups

Enterprise environments often prefer:

User
 ↓
Group
 ↓
Role
 ↓
Resource

This makes:

Onboarding easier
Offboarding easier
Access reviews easier
Governance more consistent

Group Review Questions

Ask:

What is the purpose of the group?
Who owns the group?
Who are its members?
Is the role appropriate?
Is the access still needed?

Part 8 — Review Service Accounts

Navigate to:

IAM & Admin
    ↓
Service Accounts

Review available service accounts.

For each service account, identify:

Name
Purpose
Attached workload
Assigned permissions
Key usage
Whether it is still required

Service Account Security Model

Application
    ↓
Service Account
    ↓
IAM Role
    ↓
Cloud Resources

If the service account has excessive privilege, a compromised application may inherit that privilege.

Part 9 — Identify Service Account Purpose

Each service account should have a clear purpose.

For example:

web-app-sa

might be expected to access:

Specific Storage Bucket

but not:

Entire Project Administration

Document service accounts with unclear ownership or purpose.

Part 10 — Review Service Account Roles

For each service account, ask:

What does the workload need to do?
        ↓
Which permissions are actually required?
        ↓
Which role is currently assigned?
        ↓
Is the current role broader?

This comparison helps identify excessive privilege.

Part 11 — Review Service Account Keys

Where appropriate, review whether service account keys exist.

Long-lived keys should be treated carefully.

Potential risks include:

Accidental exposure
Repository leakage
Local file leakage
Forgotten credentials
Uncontrolled copying

Security Question

Ask:

Does this workload actually require a downloadable service account key?

If a managed identity mechanism can be used instead, that may be preferable.

Part 12 — Key Inventory

Create a simple key review table.

Service Account	Key Present?	Required?	Risk
app-sa	Yes	Review	Medium
automation-sa	No	N/A	Low

Do not remove legitimate keys unless the lab scenario authorizes remediation.

Part 13 — Service Account Impersonation

Another important security relationship is impersonation.

A principal may have permission to act as a service account.

Conceptually:

User
  ↓
Impersonation Permission
  ↓
Service Account
  ↓
Privileged Resource

This means the user’s effective access may be greater than their directly assigned roles suggest.

Privilege Path Thinking

Suppose:

User
 ↓
Low Privilege Role

appears safe.

But then:

User
 ↓
Can Impersonate
 ↓
Highly Privileged Service Account

The actual risk is very different.

Always evaluate identity relationships.

Part 14 — Understand IAM Scope

IAM can be assigned at different levels.

Organization
     ↓
Folder
     ↓
Project
     ↓
Resource

A role visible at the project may have been inherited from above.

This matters during security assessment.

Part 15 — Identify Inherited Permissions

For selected principals, determine whether access is:

Direct
Inherited
Group-based
Service-account-related

Ask:

Where was this access granted?

Removing a direct project role may not remove access if another role is inherited from a folder or organization.

Part 16 — Effective Access

The security question is not simply:

What role is shown here?

It is:

What can this identity effectively do?

Effective access may come from:

Direct Role
   +
Group Membership
   +
Inherited Role
   +
Impersonation Capability

This is why IAM assessments can become complex.

Part 17 — Identify Sensitive Roles

Look for roles related to high-risk capabilities such as:

IAM administration
Project administration
Service account administration
Networking administration
Key management
Security administration
Logging administration

These roles deserve deeper review.

Risk-Based Review

Not every role needs the same level of investigation.

Prioritize:

Privilege
   +
Scope
   +
Identity Type
   +
Resource Sensitivity

For example:

Privileged Role
      +
Service Account
      +
Production Scope

should receive more scrutiny than a read-only role in a training project.

Part 18 — Create a Controlled Least-Privilege Scenario

In your authorized lab project, create a simple access scenario.

For example:

Lab User
   ↓
Broad Role
   ↓
Test Resource

The goal is to analyze why the role is broader than necessary.

Do not use a real production identity.

Part 19 — Identify the Required Task

Suppose the lab identity only needs to:

View Objects

in a specific storage resource.

Ask:

Does the identity need project-wide Editor privileges?

No.

The business task should drive the permissions.

Part 20 — Replace Broad Access

In the controlled lab scenario, replace excessive access with a narrower role appropriate for the required task.

Conceptually:

Before

Lab User
   ↓
Broad Project Role

becomes:

After

Lab User
   ↓
Specific Role
   ↓
Required Resource

Validate the Change

Least privilege is not complete until functionality is validated.

Check:

Required Action
      ↓
Still Works?

and:

Unnecessary Action
      ↓
Now Blocked?

A successful remediation satisfies both.

Part 21 — Understand the Least-Privilege Cycle

Use this model:

Identify Business Need
        ↓
Determine Required Permissions
        ↓
Assign Narrow Role
        ↓
Scope Correctly
        ↓
Test
        ↓
Monitor
        ↓
Review Periodically

Least privilege is an ongoing process.

Part 22 — Review Custom Roles

If your environment contains custom roles, review them.

Ask:

Why was the role created?
Which permissions does it include?
Is it still required?
Is a predefined role now available?
Does it contain sensitive permissions?

Do not assume a custom role is automatically safer.

Custom Role Risk

A custom role may have a harmless name but contain powerful permissions.

Always assess:

Permissions

rather than trusting:

Role Name

Part 23 — Review Unused Access

Look for indicators that access may no longer be required.

Examples:

Old users
Temporary project access
Former project members
Unused service accounts
Legacy automation identities

Unused privileged access increases attack surface.

Access Review Question

Ask:

If this access were removed today, would anyone notice?

If nobody knows why it exists, it deserves review.

Part 24 — Review External Identities

If applicable, identify principals outside the expected organization or domain.

Do not assume external access is malicious.

It may be legitimate for:

Vendors
Consultants
Partners
Support teams

But external access should have:

Clear purpose
Appropriate scope
Defined owner
Review date

Part 25 — Review Privilege by Environment

Different environments may have different risk levels.

For example:

Sandbox
   ↓
Lower Business Impact

Production
   ↓
Higher Business Impact

A broad role in production typically deserves greater scrutiny.

Part 26 — Review Separation of Duties

Sensitive actions should not always be concentrated under one identity.

For example:

Application Team
      ↓
Deploy Workload

Security Team
      ↓
Review Security

Key Management Team
      ↓
Manage Encryption Keys

This can reduce the risk of one account controlling every layer.

Part 27 — Review IAM Changes in Cloud Logging

Return to Cloud Logging.

Review IAM-related administrative activity.

You may use the lab changes you generated.

Identify:

Principal making the change
Resource affected
Time
Method
Result

This connects the previous logging lab with IAM security.

Security Value

IAM configuration tells you:

Who Has Access Now

Audit logs help tell you:

Who Changed Access

Both views are required.

Part 28 — Build an IAM Change Timeline

Create a simple timeline.

10:00
Lab identity created

10:05
Broad role assigned

10:15
IAM review performed

10:25
Broad role removed

10:26
Least-privilege role assigned

10:30
Access validated

This helps demonstrate remediation history.

Part 29 — Identify Potential IAM Findings

Your assessment may uncover findings such as:

Finding 1 — Broad Basic Role

Principal:
Developer

Role:
Editor

Scope:
Entire Project

Finding 2 — Privileged Service Account

Principal:
Application Service Account

Role:
Highly Privileged

Scope:
Production Project

Finding 3 — Unused Identity

Principal:
Legacy User

Business Requirement:
Unknown

Finding 4 — Long-Lived Service Account Key

Service Account:
Automation Identity

Key:
Long-Lived Credential

Finding 5 — Excessive Resource Scope

Required:
One Resource

Actual:
Entire Project

Part 30 — Rate IAM Findings

Use simple risk categories.

Critical

Access could lead directly to major administrative compromise.

High

Significant excessive privilege over sensitive resources.

Medium

Security weakness with meaningful but limited impact.

Low

Governance or hygiene issue with lower immediate impact.

Always explain why you selected the risk.

Part 31 — Document a Professional Finding

Use this structure:

Finding:
Over-Privileged IAM Assignment

Risk:
High

Affected Principal:
lab-user@example.com

Affected Scope:
GCP Project

Evidence:
Principal was assigned a broad role despite requiring access only to a specific resource.

Impact:
Compromise of the principal could allow unauthorized changes beyond the user's business responsibilities.

Recommendation:
Replace the broad role with the minimum predefined role required and scope access to the necessary resource.

Validation:
Confirm required operations still succeed and unnecessary administrative operations are denied.

Part 32 — Build an IAM Evidence Table

Use:

Principal	Type	Role	Scope	Risk	Recommendation
User A	User	Broad Role	Project	High	Reduce privilege
App SA	Service Account	Service Role	Project	Review	Validate scope
Legacy User	User	Viewer	Project	Medium	Confirm business need

This creates a clear security assessment record.

Part 33 — Build Your IAM Review Workflow

Use this repeatable process:

01 Identify Scope
        ↓
02 Inventory Principals
        ↓
03 Review Roles
        ↓
04 Identify Privileged Access
        ↓
05 Review Service Accounts
        ↓
06 Review Service Account Keys
        ↓
07 Review Impersonation Paths
        ↓
08 Review IAM Inheritance
        ↓
09 Check Business Requirement
        ↓
10 Identify Excess Privilege
        ↓
11 Recommend Least Privilege
        ↓
12 Validate Remediation

Part 34 — Think in Privilege Paths

Do not review IAM as isolated rows in a table.

Think about relationships.

Example:

Developer
   ↓
Service Account User
   ↓
Deployment Service Account
   ↓
Powerful Project Role
   ↓
Sensitive Resources

This chain may represent more risk than a direct role assignment.

Part 35 — Think Like an Attacker, Defend Like an Engineer

During a defensive review, ask:

If this identity were compromised,
what could it reach next?

Then identify controls that reduce the blast radius.

Examples include:

Narrower roles
Reduced scope
Managed workload identity
Removal of unnecessary keys
Separation of duties

Part 36 — Common IAM Security Mistakes

Watch for:

Owner assigned unnecessarily
Editor assigned broadly
Permissions assigned directly to many users
Excessively privileged service accounts
Unused service accounts
Long-lived keys
Unclear custom roles
Excessive inherited access
Unreviewed external users
Large project-wide scope

Part 37 — Common Mistake: Role Name Trust

Do not assume:

Role Name Sounds Safe

means:

Permissions Are Safe

Always evaluate capabilities.

Part 38 — Common Mistake: Reviewing Only Human Users

Service accounts can be more important than human identities.

An application identity may have:

24/7 Access
        +
No Interactive Login
        +
Broad Automation Capability

That makes service-account security critical.

Part 39 — Common Mistake: Ignoring Inheritance

An IAM role may disappear from the project and the identity may still retain access.

Always consider inherited permissions.

Part 40 — Common Mistake: Removing Access Without Testing

Security changes can break production workloads.

Use:

Reduce Access
   ↓
Test
   ↓
Validate Application
   ↓
Confirm Security

Security and availability must both be considered.

Lab Challenge 1 — Find the Most Privileged Identity

Review your authorized lab environment.

Identify the most privileged principal.

Explain:

Why it is privileged
Whether the access is expected
What the compromise impact could be

Lab Challenge 2 — Find an Over-Privileged Service Account

Review service accounts.

Choose one and determine whether its permissions match its workload purpose.

Document your reasoning.

Lab Challenge 3 — Trace Effective Access

Choose a principal.

Determine whether its access comes from:

Direct role
Group
Inheritance
Impersonation

Document the effective access path.

Lab Challenge 4 — Perform Least-Privilege Remediation

Use a controlled lab principal.

Start with access that is intentionally broader than required.

Reduce it to the minimum appropriate role.

Validate functionality.

Lab Challenge 5 — Investigate an IAM Change

Using Cloud Logging, identify an IAM change you made during the lab.

Record:

Who changed access
When
Which resource
What type of IAM operation occurred

Lab Challenge 6 — Create an IAM Risk Register

Create a small table:

Finding	Principal	Risk	Remediation
Excess privilege	Lab User	High	Narrow role
Key exposure risk	App SA	Medium	Remove unnecessary key
Unused access	Legacy User	Medium	Confirm/remove

This begins connecting IAM assessment with enterprise risk management.

Lab Success Criteria

You have completed this lab successfully when you can:

Identify IAM principals
Classify identity types
Review role assignments
Identify broad roles
Review service accounts
Understand service account key risk
Recognize impersonation relationships
Understand IAM inheritance
Identify excessive privilege
Recommend least privilege
Validate access after remediation
Document security findings

IAM Assessment Checklist

Confirmed project scope
Inventoried users
Inventoried groups
Inventoried service accounts
Reviewed basic roles
Reviewed privileged predefined roles
Reviewed custom roles
Reviewed inherited permissions
Reviewed service account privileges
Reviewed service account keys
Reviewed impersonation relationships
Identified unnecessary access
Performed controlled least-privilege remediation
Validated required access
Reviewed IAM audit activity
Documented findings

Interview Questions to Practice

After completing the lab, you should be able to answer:

How does Google Cloud IAM work?
What is a principal?
What is the difference between a role and a permission?
What are basic roles?
Why should Owner and Editor be reviewed carefully?
What are predefined roles?
When would you use a custom role?
What is least privilege?
What is IAM inheritance?
What is effective access?
Why are groups useful for IAM management?
What is a service account?
Why are service accounts security-sensitive?
Why can service account keys be risky?
What is service account impersonation?
How could impersonation create a privilege path?
How would you review project IAM?
How would you identify excessive permissions?
How would you validate a least-privilege change?
How would you investigate an IAM change?

Security Engineer Takeaway

IAM reviews should never be reduced to:

List Users
        ↓
Check Roles
        ↓
Done

A stronger security review looks like:

Principal
   ↓
Role
   ↓
Permissions
   ↓
Scope
   ↓
Inheritance
   ↓
Impersonation
   ↓
Business Need
   ↓
Effective Risk

The most important question is:

Does this identity have exactly the access it requires, and no more?

That question should guide every IAM security assessment.

Clean Up

After completing the lab:

Remove temporary IAM bindings
Remove disposable lab identities if appropriate
Remove unused service account keys
Restore the authorized project baseline
Confirm legitimate access still works

Do not remove access that existed before the lab unless the environment owner has explicitly approved it.

What’s Next?

➡️ Lab 03 — GCP Incident Response

In the next lab, you will combine IAM and logging knowledge to investigate a simulated Google Cloud security incident.

You will work through:

Security Alert
      ↓
Initial Triage
      ↓
Identify Principal
      ↓
Review Audit Logs
      ↓
Identify Affected Resources
      ↓
Determine Scope
      ↓
Containment
      ↓
Evidence Collection
      ↓
Remediation
      ↓
Recovery
      ↓
Incident Report

This will move you from security configuration review into real cloud incident investigation and response.