Project 03 — Google Cloud IAM & Workload Security Assessment

Welcome

Welcome to Project 03 — Google Cloud IAM & Workload Security Assessment.

You have already completed enterprise projects covering:

Project 01
AWS
 ↓
IAM Roles
Workload Roles
Resource Policies
Trust Relationships

Project 02
Azure
 ↓
Microsoft Entra ID
Azure RBAC
Managed Identities
Resource Control

You will now apply the same enterprise attack-path methodology to Google Cloud.

Google Cloud introduces an important security model built around:

Organisation
     ↓
Folders
     ↓
Projects
     ↓
Resources

combined with:

Human Identities
      +
Groups
      +
IAM Roles
      +
Service Accounts
      +
Workload Identities

One of the most important concepts in this project is:

A workload’s service account can be more privileged than the person who controls the workload.

Your mission is therefore not simply to identify vulnerable Google Cloud resources.

You must determine:

Can human identities, inherited IAM permissions, service accounts, workloads, and cloud trust relationships combine into a path toward sensitive Google Cloud resources?

Mission Information

Project

Google Cloud IAM & Workload Security Assessment

Platform

CloudNova

Difficulty

Intermediate → Advanced

Estimated Time

4–6 hours

Primary Skills

Google Cloud reconnaissance
Organisation hierarchy analysis
Project discovery
IAM policy analysis
IAM inheritance analysis
Service account assessment
Workload identity analysis
Compute Engine assessment
Cloud Storage security
Secret Manager assessment
Serverless security
Network exposure analysis
Audit logging review
Privilege-path development
Evidence collection
Professional reporting

Mission Objective

A fictional organisation has requested an authorised security assessment of its Google Cloud environment hosted in CloudNova.

The organisation uses:

Google Cloud Organisation
          ↓
        Folders
          ↓
        Projects
          ↓
 ┌────────┼─────────┐
 ↓        ↓         ↓
Compute  Storage  Serverless
 ↓                  ↓
Service Accounts / Workload Identities
          ↓
    Cloud Resources

The organisation is concerned about:

Excessive IAM permissions
Broad inherited permissions
Overprivileged service accounts
Weak service account relationships
Developers controlling privileged workloads
Excessive storage access
Secret Manager exposure
Unnecessary network exposure
Serverless workload privilege
Weak logging governance

Your task is to determine whether these conditions can combine into meaningful attack paths.

Starting Position

You begin with an authorised CloudNova Google Cloud identity.

Example:

Identity:
student@cloudnova.lab

Environment:
CloudNova Google Cloud Training Environment

Starting Privilege:
Limited

Projects:
To Be Discovered

Objective:
Map the environment and determine whether
IAM and workload relationships create
unintended privilege paths.

Rules of Engagement

Allowed:

Organisation hierarchy discovery

Project enumeration

Resource enumeration

IAM policy review

Service account enumeration

Service account permission analysis

Compute configuration review

Cloud Storage review

Secret Manager permission review

Serverless configuration review

Network configuration review

Audit logging review

Controlled permission validation

Evidence collection

Not allowed unless explicitly required by CloudNova:

Denial of Service

Deleting projects

Deleting workloads

Destroying data

Disabling logging

Creating persistent unauthorised access

Testing unrelated Google Cloud projects

Testing third-party infrastructure

Downloading unnecessary sensitive data

Golden Rule

Use:

Minimum Necessary Validation

The objective is to prove the security relationship—not to maximise the impact.

Project Success Criteria

By the end of the project, produce:

Google Cloud Architecture Diagram

Organisation Hierarchy Map

Project Inventory

IAM Binding Matrix

Service Account Inventory

Workload Identity Map

Compute Assessment

Network Exposure Matrix

Cloud Storage Assessment

Secret Manager Assessment

Serverless Assessment

Logging Assessment

Attack Path Register

Evidence Register

Findings Register

Enterprise GCP Penetration Testing Report

Phase 01 — Prepare Your Project Workspace

Create:

Project 03 - Enterprise GCP Pentest/
│
├── 01 Engagement
├── 02 Architecture
├── 03 Organisation
├── 04 Projects
├── 05 IAM
├── 06 Service Accounts
├── 07 Compute
├── 08 Network
├── 09 Storage
├── 10 Secrets
├── 11 Serverless
├── 12 Logging
├── 13 Attack Paths
├── 14 Evidence
├── 15 Findings
├── 16 Report
└── 17 Retest

Inside 01 Engagement create:

Scope.md
Rules-of-Engagement.md
Objectives.md
Testing-Notes.md

Phase 02 — Document Scope

Create:

Cloud Provider:
Google Cloud

Environment:
CloudNova

Organisation:
<ORG-ID>

Folders:
<AUTHORISED-FOLDERS>

Projects:
<AUTHORISED-PROJECTS>

Starting Identity:
<IDENTITY>

In Scope:
IAM
Service Accounts
Compute Engine
Cloud Storage
Secret Manager
Serverless
Networking
Logging
Approved Resources

Out of Scope:
Other Organisations
Third-Party Projects
DoS
Destructive Actions
Unapproved Resources

Phase 03 — Establish Your Current Identity

Your first question should again be:

Who am I?

In the authorised CloudNova environment:

gcloud auth list

Review the active identity.

You can also inspect configuration:

gcloud config list

Record:

Active Account

Current Project

Region

Zone

Configuration

Create:

Evidence ID:
GCP-EV-001

Phase 04 — Understand the GCP Resource Hierarchy

Google Cloud commonly follows:

Organisation
      ↓
Folder
      ↓
Subfolder
      ↓
Project
      ↓
Resource

Example:

cloudnova.lab
│
├── Production
│   ├── Web Project
│   └── Data Project
│
├── Development
│   └── Dev Project
│
└── Security
    └── Logging Project

This hierarchy matters because IAM permissions can be inherited.

Phase 05 — IAM Inheritance

Suppose a group receives a role at:

Organisation

That permission may affect resources below it.

Similarly:

Folder
 ↓
Project A
Project B
Project C

A folder-level IAM assignment may influence multiple projects.

Therefore:

Never assess Google Cloud IAM only at the individual resource level.

Phase 06 — Discover Projects

Where authorised:

gcloud projects list

Create:

Project	Project ID	Purpose	Criticality	In Scope
Web	cloudnova-web	Application	High	Yes
Data	cloudnova-data	Data	Critical	Yes
Dev	cloudnova-dev	Development	Medium	Yes
Security	cloudnova-security	Logging	Critical	Yes

Do not interact with projects outside the authorised scope.

Phase 07 — Set Project Context

For a specific authorised project:

gcloud config set project <PROJECT-ID>

Then confirm:

gcloud config get-value project

Always know which project you are operating against.

Phase 08 — Build the Initial Architecture

Example:

Google Cloud Organisation
          │
          ├── Production
          │      │
          │      ├── cloudnova-web
          │      │      └── Compute
          │      │
          │      └── cloudnova-data
          │             ├── Storage
          │             └── Secrets
          │
          ├── Development
          │      └── cloudnova-dev
          │
          └── Security
                 └── cloudnova-security
                        └── Logging

This will evolve throughout the project.

Phase 09 — Inventory Compute Resources

For an authorised project:

gcloud compute instances list

Create:

Instance	Project	Zone	Public IP	Service Account	Purpose
web01	cloudnova-web	zone-a	Yes	web-sa	Web
app01	cloudnova-web	zone-a	No	app-sa	Application
admin01	cloudnova-security	zone-b	No	admin-sa	Management

Phase 10 — Inventory Cloud Storage

Where permitted:

gcloud storage buckets list

Create:

Bucket	Project	Purpose	Exposure	Criticality
app-data	Data	Application	Unknown	High
backups	Data	Backup	Unknown	Critical
public-assets	Web	Static assets	Public?	Low

Unknown values are acceptable at this stage.

You are building an inventory—not making conclusions.

Phase 11 — Inventory Service Accounts

Use:

gcloud iam service-accounts list

Record:

Service Account Name

Email

Project

Purpose

Associated Workload

Known Roles

Create:

Service Account	Project	Workload	Privilege
web-sa	Web	WEB01	Unknown
app-sa	Web	APP01	Unknown
processor-sa	Data	Serverless	Unknown

Phase 12 — Why Service Accounts Matter

A service account represents a machine or workload identity.

Conceptually:

Application
     ↓
Service Account
     ↓
IAM Role
     ↓
Cloud Resource

A human user might have limited permissions but control a workload using a powerful service account.

This creates:

Human Identity
      ↓
Workload Control
      ↓
Service Account
      ↓
Higher Privilege

Phase 13 — Build the Identity Inventory

Include:

Human Users

Groups

Service Accounts

Workload Identities

Automation Identities

Example:

Identity	Type	Project	Purpose	Privileged
student	Human	Dev	Development	No
Developers	Group	Dev	Development	Review
app-sa	Service Account	Web	Application	Review
security-sa	Service Account	Security	Logging	High

Phase 14 — Review Project IAM

Where authorised:

gcloud projects get-iam-policy <PROJECT-ID>

For easier review:

gcloud projects get-iam-policy <PROJECT-ID> \
  --format="table(bindings.role,bindings.members)"

Record:

Principal

Role

Scope

Project

Inherited?

Purpose

Phase 15 — IAM Binding Model

Think of every binding as:

Principal
    ↓
Role
    ↓
Permissions
    ↓
Scope
    ↓
Resource

Do not stop at:

User has Role X

Ask:

What can that role actually influence?

Phase 16 — Build the IAM Matrix

Create:

Principal	Role	Scope	Resource	Security Question
Developers	Viewer	Dev	Project	Recon only?
student	CustomAppManager	Web	Project	Workload control?
app-sa	Secret Accessor	Data	Secret	Required?
automation-sa	Editor	Web	Project	Too broad?

Phase 17 — Built-In Roles

Be familiar with concepts such as:

Viewer

Editor

Owner

Modern environments also use many service-specific roles.

The important principle is:

Role names are only labels. Effective permissions determine security impact.

Phase 18 — Custom Roles

Where authorised, review custom roles.

Ask:

Which Permissions?

Which Scope?

Which Principals?

Why Does the Role Exist?

Can It Modify Workloads?

Can It Manage IAM?

Can It Access Secrets?

Can It Control Service Accounts?

Phase 19 — Permission Categories

Classify important permissions into:

Read

Write

Resource Creation

Resource Modification

IAM Modification

Service Account Control

Credential Management

Secret Access

Network Modification

Logging Modification

Pay particular attention to:

Service Account Control

because it can bridge identities.

Phase 20 — Service Account IAM Policies

For an authorised service account:

gcloud iam service-accounts get-iam-policy \
  <SERVICE-ACCOUNT-EMAIL>

Ask:

Who Can Use This Identity?

Who Can Manage This Identity?

Who Can Change Its Policy?

Which Workloads Use It?

What Permissions Does It Have?

Phase 21 — Two Sides of Service Account Security

Always analyse:

Who Can Become / Use the Service Account?

and:

What Can the Service Account Do?

These are different questions.

Conceptually:

Developer
    ↓
Can Use
    ↓
Service Account
    ↓
Has Access To
    ↓
Sensitive Resource

Phase 22 — Service Account Impersonation Concept

Google Cloud supports authorised service account impersonation.

From a security perspective, examine:

Human Identity
      ↓
Impersonation Permission
      ↓
Service Account
      ↓
Effective Permissions

Do not assume service-account impersonation is insecure.

It is often preferable to static credentials.

The issue is:

Who is allowed to impersonate which service account, and what privilege does that service account possess?

Phase 23 — Create the Hypothesis Register

Example:

ID	Hypothesis	Evidence Needed	Status
GCP-H-001	Developer may use privileged app service account	SA IAM	Investigate
GCP-H-002	app-sa may access sensitive secrets	IAM binding	Investigate
GCP-H-003	Data bucket may be broadly readable	Storage IAM	Investigate
GCP-H-004	Workload may have unnecessary network exposure	Firewall	Investigate

A hypothesis is not a finding.

Phase 24 — Workload Control Analysis

Suppose:

student
   ↓
Can Modify
   ↓
APP01

APP01 uses:

app-sa

and:

app-sa
   ↓
Secret Access
   ↓
production-secret

Potential path:

student
   ↓
APP01 Control
   ↓
app-sa
   ↓
Secret Access

This relationship deserves investigation.

Phase 25 — Compute Engine Assessment

For each instance assess:

Project

Zone

Public IP

Private IP

Firewall Exposure

Service Account

Access Scope

Labels

Purpose

Administrative Access

Phase 26 — Inspect a VM

Where authorised:

gcloud compute instances describe <INSTANCE-NAME> \
  --zone <ZONE>

Pay particular attention to:

serviceAccounts

and network configuration.

Phase 27 — Compute Identity Map

Build:

WEB01
 ↓
web-sa
 ↓
IAM Roles
 ↓
Cloud Resources

and:

APP01
 ↓
app-sa
 ↓
Secrets / Storage

Phase 28 — Compute Security Questions

Ask:

Does the Instance Need a Public IP?

Which Firewall Rules Reach It?

Which Service Account Is Attached?

Does the Workload Need Those Permissions?

Who Can Modify the Instance?

Who Can Administer It?

Can It Reach Sensitive Internal Resources?

Phase 29 — Network Inventory

List firewall rules:

gcloud compute firewall-rules list

Create:

Rule	Source	Target	Port	Expected?
allow-web	Internet	web	443	Yes
allow-admin	Internet	admin	22	Review
allow-app	web	app	8080	Yes

Phase 30 — Network Exposure Analysis

Ask:

What Is Internet Facing?

Why?

Which Protocols?

Which Sources?

Which Workloads?

Could Exposure Be Reduced?

Phase 31 — Firewall Rules and Identity

Do not analyse networking separately from IAM.

Example:

Internet
   ↓
WEB01
   ↓
web-sa
   ↓
Cloud Resources

A network-exposed workload carrying a powerful identity can increase the potential blast radius.

Phase 32 — VPC Architecture

Map:

VPC
│
├── Web Subnet
│
├── Application Subnet
│
└── Management Subnet

Then map trust:

Internet
   ↓
Web
   ↓
Application
   ↓
Data

Ask whether each transition is intentional.

Phase 33 — Cloud Storage Assessment

For an authorised bucket:

gcloud storage buckets describe gs://<BUCKET-NAME>

Review:

IAM

Public Access Prevention

Uniform Bucket-Level Access

Encryption

Versioning

Retention

Logging

Location

Phase 34 — Review Bucket IAM

Where permitted:

gcloud storage buckets get-iam-policy gs://<BUCKET-NAME>

Ask:

Who Can Read?

Who Can Write?

Who Can Delete?

Is Anonymous Access Present?

Are Service Accounts Overprivileged?

Is Access Cross-Project?

Phase 35 — Public Access

Public access is not automatically a vulnerability.

Example:

public-assets

may intentionally host public website assets.

The real questions are:

Is Public Access Intended?

Is Sensitive Data Present?

Is Write Access Public?

Could Sensitive Data Be Added Accidentally?

Phase 36 — Storage Finding Example

GCP-001 — Application Service Account Has Excessive Access to Sensitive Cloud Storage

Observation

The service account assigned to an application workload has access to a storage resource beyond its documented business requirement.

Impact

Compromise of the application workload could expand into unauthorised access to unrelated cloud data.

Root Cause

Excessive permissions assigned to the workload identity.

Recommendation

Restrict the service account to the minimum required storage resources and operations.

Phase 37 — Secret Manager Discovery

Where permitted:

gcloud secrets list

Start with metadata.

Do not automatically retrieve secret values.

Phase 38 — Secret Manager Questions

Ask:

Which Secrets Exist?

Which Workloads Use Them?

Which Identities Can Access Them?

Which Identities Can Modify Them?

Who Can Change IAM?

Are Secrets Shared Across Applications?

Phase 39 — Secret Access as an Attack Transition

Example:

APP01
 ↓
app-sa
 ↓
Secret Access
 ↓
Database Credential
 ↓
Database

The finding is not simply:

Service account can read secret.

The important question is:

Should this workload have access to the system protected by that secret?

Phase 40 — Avoid Unnecessary Secret Retrieval

If IAM evidence already demonstrates access:

Permission Evidence
      ↓
Potential Impact

may be sufficient.

If CloudNova specifically requires validation, retrieve only an approved synthetic marker and handle it according to the lab instructions.

Phase 41 — Serverless Discovery

Google Cloud environments may include services such as:

Cloud Run

Cloud Functions

Where authorised, inventory relevant workloads.

For example:

gcloud run services list

Phase 42 — Serverless Security Model

Think:

Internet / Internal Caller
          ↓
      Cloud Run
          ↓
    Service Account
          ↓
     IAM Permissions
          ↓
       Resources

Phase 43 — Serverless Questions

Ask:

Is the Service Public?

Who Can Invoke It?

Which Service Account Does It Use?

Who Can Modify the Service?

What Environment Configuration Exists?

Which Secrets Can It Access?

What Network Access Exists?

Phase 44 — Workload Identity Risk

Suppose:

Developer
    ↓
Can Deploy
    ↓
Cloud Run Service
    ↓
Runs As
    ↓
processor-sa
    ↓
Sensitive Data Access

Potential attack path:

Developer
 ↓
Deployment Control
 ↓
Privileged Workload
 ↓
Service Account
 ↓
Sensitive Resource

Phase 45 — Service Account Keys

Service accounts can historically use static key material.

From a security perspective ask:

Do User-Managed Keys Exist?

Are They Necessary?

How Old Are They?

Where Are They Stored?

Can Workload Identity or Federation Replace Them?

Long-lived credentials increase operational risk.

Prefer managed identity mechanisms where possible.

Phase 46 — Key Management Principle

Think:

Long-Lived Static Credential
             ↓
     Theft / Leakage Risk

versus:

Managed / Federated Identity
             ↓
   Short-Lived Credentials

This does not make federated identity automatically secure.

IAM relationships still matter.

Phase 47 — Cross-Project Access

Google Cloud environments frequently separate resources across projects.

Example:

cloudnova-web
      ↓
app-sa
      ↓
cloudnova-data
      ↓
Storage

Document:

Source Project

Identity

Target Project

Role

Target Resource

Business Requirement

Phase 48 — Cross-Project Attack Paths

Example:

Developer
   ↓
Controls Workload
   ↓
app-sa
   ↓
Cross-Project Role
   ↓
Data Project
   ↓
Sensitive Storage

Cross-project relationships can make privilege paths difficult to see without graph-based analysis.

Phase 49 — Organisation-Level IAM

Where the lab exposes organisation-level information, review it carefully.

Ask:

Which Roles Exist at Organisation Scope?

Which Groups Receive Them?

Are Permissions Inherited?

Do Development Identities Receive Enterprise-Wide Visibility?

Are Privileged Roles Centrally Governed?

Phase 50 — Folder-Level IAM

Folder permissions can influence multiple projects.

Example:

Production Folder
      ↓
Security Admin Group
      ↓
Projects A / B / C

This may be intentional.

Your task is to evaluate whether:

Privilege
   =
Business Requirement

Phase 51 — IAM Inheritance Map

Create:

Organisation
│
├── Role A → Security Group
│
└── Production Folder
     │
     ├── Role B → Platform Team
     │
     ├── Web Project
     │    └── Role C → Developers
     │
     └── Data Project
          └── Role D → app-sa

Phase 52 — Effective Permission Thinking

A principal’s real privilege may come from:

Organisation Binding
       +
Folder Binding
       +
Project Binding
       +
Resource Binding
       =
Effective Access

Do not review these independently.

Phase 53 — Build the Identity Graph

Example:

student
   │
   └── Developers
           │
           └── Workload Manager → cloudnova-web
                                    │
                                    ↓
                                  APP01
                                    │
                                    ↓
                                  app-sa
                                    │
                     ┌──────────────┴─────────────┐
                     ↓                            ↓
               Secret Access               Storage Access
                     ↓                            ↓
               Data Project                 Data Project

Phase 54 — Identify Privilege Choke Points

Potential choke points:

Developers Workload Role

APP01 Control

app-sa

Cross-Project IAM Binding

Secret Manager Role

Ask:

Which single control change breaks the largest number of dangerous paths?

Phase 55 — Attack Path 01

Example:

student
   ↓
Developers Group
   ↓
Workload Modification
   ↓
APP01
   ↓
app-sa
   ↓
Sensitive Storage

Document every transition.

Phase 56 — Attack Path 02

Example:

Developer
   ↓
Serverless Deployment
   ↓
Cloud Run
   ↓
processor-sa
   ↓
Secret Manager
   ↓
Sensitive Service

Phase 57 — Attack Path 03

Example:

Low-Privilege Identity
       ↓
Service Account Usage Permission
       ↓
Privileged Service Account
       ↓
Cross-Project Role
       ↓
Critical Data Project

Again, only mark this as validated when the actual IAM relationships support it.

Phase 58 — Attack Path Register

Create:

Path	Start	Transition	Critical Resource	Status	Risk
GCP-AP-001	student	APP01 → app-sa	Storage	Validated	High
GCP-AP-002	developer	Cloud Run → processor-sa	Secret	Investigate	TBD
GCP-AP-003	user	Service account relationship	Data project	Validated	High

Phase 59 — Controlled Validation

For every hypothesis:

Hypothesis
    ↓
Configuration Evidence
    ↓
Enough?
   /    \
 Yes     No
 ↓       ↓
Stop   Minimal Safe Validation
          ↓
        Evidence
          ↓
         Stop

Do not continue simply because additional access is technically possible.

Phase 60 — Logging Assessment

Important Google Cloud telemetry may include:

Cloud Audit Logs

Admin Activity Logs

Data Access Logs

System Event Logs

Policy Denied Logs

Cloud Logging

Security Command Center

Phase 61 — Audit Log Questions

Ask:

Are Administrative Actions Logged?

Are IAM Changes Logged?

Are Service Account Actions Logged?

Are Secret Access Events Visible?

Are Sensitive Data Access Events Logged?

Are Logs Centralised?

Who Can Modify Logging?

Who Can Delete Logs?

Phase 62 — Logging Governance

A security-sensitive identity should not unnecessarily possess the ability to:

Reduce Logging

Delete Logs

Change Log Destinations

Disable Security Visibility

Do not modify logging during the assessment.

Phase 63 — Detection Analysis

For each attack path ask:

Attack Step
    ↓
Which GCP Event?
    ↓
Which Log?
    ↓
Which Detection?
    ↓
Which Alert?

Example:

IAM Policy Change
      ↓
Audit Log
      ↓
Security Detection
      ↓
SOC Investigation

Phase 64 — Evidence Register

Create:

GCP-EV-001
Current identity

GCP-EV-002
Project inventory

GCP-EV-003
Project IAM policy

GCP-EV-004
Service account inventory

GCP-EV-005
Service account IAM relationship

GCP-EV-006
Compute workload identity

GCP-EV-007
Storage IAM

GCP-EV-008
Secret Manager IAM

GCP-EV-009
Firewall configuration

GCP-EV-010
Controlled validation

Phase 65 — Evidence Template

Use:

Evidence ID:
GCP-EV-006

Timestamp:
<DATE/TIME>

Project:
cloudnova-web

Resource:
APP01

Observation:
APP01 operates using app-sa.

Security Relevance:
The service account has access to resources
outside the workload's documented requirement.

Attack Path:
GCP-AP-001

Sensitive Data Collected:
None

Phase 66 — Finding Example 01

GCP-001 — Developer Workload Control Creates an Indirect Path to a Privileged Service Account

Recommendation

Replace long-lived credentials with managed, federated, or short-lived identity mechanisms wherever operationally feasible.

Phase 72 — Positive Security Observations

Document what works.

Examples:

Sensitive Buckets Not Public
        ✓

Public Access Prevention Enabled
        ✓

Dedicated Service Accounts
        ✓

Audit Logging Enabled
        ✓

Administrative VM Has No Public IP
        ✓

Production and Development Separated
        ✓

Phase 73 — Root Cause Analysis

Look for systemic themes such as:

Overprivileged Service Accounts

Broad IAM Scope

Weak Workload Identity Governance

Cross-Project Trust Sprawl

Excessive Developer Control

Long-Lived Credentials

Weak Network Segmentation

Inconsistent Logging Governance

Phase 74 — Risk Prioritisation

Consider:

Starting Privilege

IAM Scope

Workload Control

Service Account Privilege

Cross-Project Reach

Data Sensitivity

Network Exposure

Detection Coverage

Business Impact

Phase 75 — Remediation Priorities

Immediate

Break validated critical identity paths

Remove unnecessary cross-project access

Reduce excessive service account privilege

Restrict exposed management services

Remove unnecessary long-lived credentials

Short Term

Review service account IAM

Review project IAM

Review inherited permissions

Review serverless identities

Improve network segmentation

Review Secret Manager access

Strategic

Workload Identity Governance

Service Account Lifecycle Management

IAM Access Reviews

Organisation Policy Governance

Centralised Logging

Privileged Access Governance

Continuous Attack-Path Analysis

Phase 76 — Remediation Matrix

Create:

Finding	Immediate	Strategic	Owner
GCP-001	Restrict workload control	Separation of duties	Platform
GCP-002	Remove storage access	Cross-project IAM governance	IAM
GCP-003	Restrict SA usage	Service account governance	Security
GCP-004	Restrict firewall	Secure management network	Network
GCP-005	Create dedicated SA	Workload IAM baseline	DevOps
GCP-006	Replace static key	Workload identity federation	IAM

Phase 77 — Retesting

Before:

Developer
   ↓
APP01
   ↓
app-sa
   ↓
Sensitive Storage

After remediation:

Developer
   ↓
Required APP01 Control
   ✓

APP01
   ↓
Dedicated Least-Privilege SA
   ↓
Required Application Data
   ✓

APP01
   ↓
Sensitive Unrelated Storage
   X

Phase 78 — Retest Status

Use:

Resolved

Partially Resolved

Not Resolved

Risk Accepted

Verify effective access rather than merely checking whether the policy text changed.

Phase 79 — Final Architecture Diagram

Your final diagram may resemble:

                      Google Cloud Organisation
                               │
                 ┌─────────────┼──────────────┐
                 ↓             ↓              ↓
             Production    Development     Security
                 │             │              │
          ┌──────┴──────┐      │              ↓
          ↓             ↓      ↓          Logging Project
      Web Project    Data Project
          │             │
      ┌───┴───┐      ┌──┴─────────┐
      ↓       ↓      ↓            ↓
    WEB01   APP01  Storage       Secrets
      │       │
      ↓       ↓
    web-sa   app-sa
               │
               └──────────→ Data Project

Add IAM relationships:

student
   ↓
Developers
   ↓
Workload Control
   ↓
APP01
   ↓
app-sa
   ↓
Cross-Project Access
   ↓
Sensitive Storage

Phase 80 — Final Attack Narrative

A professional narrative might read:

The assessment began with an authorised low-privileged Google Cloud identity. Project and IAM analysis identified that the identity could manage an application workload through permissions assigned to the development team. The affected workload operated using a service account with access to a sensitive storage resource in a separate data project. This created an indirect privilege path in which compromise of the development identity could potentially extend into data outside the developer’s direct permission boundary. The path resulted from the combination of workload-control permissions, an overprivileged service account, and cross-project IAM access.

This is stronger than:

The service account is vulnerable.

Phase 81 — Enterprise GCP Report Structure

Create:

Enterprise Google Cloud Penetration Testing Report

1. Executive Summary

2. Engagement Objectives

3. Scope

4. Rules of Engagement

5. Organisation Overview

6. Folder & Project Architecture

7. Methodology

8. Asset Inventory

9. IAM Assessment

10. IAM Inheritance Analysis

11. Service Account Assessment

12. Workload Identity Assessment

13. Compute Assessment

14. Network Security Assessment

15. Cloud Storage Assessment

16. Secret Manager Assessment

17. Serverless Security Assessment

18. Logging & Detection Assessment

19. Cross-Project Trust Analysis

20. Attack Paths

21. Validated Findings

22. Positive Security Observations

23. Root Cause Themes

24. Remediation Roadmap

25. Retest Plan

26. Evidence Appendix

Phase 82 — Executive Summary Questions

Your executive summary should answer:

What Was Tested?

Which Projects Were Assessed?

Which Identity Relationships Matter Most?

Could Low Privilege Expand?

Could Workload Control Lead to Higher Privilege?

Were Cross-Project Boundaries Effective?

Which Sensitive Resources Were Reachable?

Which Controls Worked?

Which Controls Failed?

What Should Be Fixed First?

Phase 83 — Final Project Deliverables

Complete:

Project 03 - Enterprise GCP Pentest/
│
├── 01 Engagement
│   ├── Scope.md
│   ├── Rules-of-Engagement.md
│   └── Objectives.md
│
├── 02 Architecture
│   ├── Initial-GCP-Architecture.md
│   └── Final-GCP-Architecture.md
│
├── 03 Organisation
│   ├── Organisation-Hierarchy.md
│   └── Folder-Inventory.md
│
├── 04 Projects
│   └── Project-Inventory.md
│
├── 05 IAM
│   ├── IAM-Binding-Matrix.md
│   ├── IAM-Inheritance-Map.md
│   └── Custom-Role-Review.md
│
├── 06 Service Accounts
│   ├── Service-Account-Inventory.md
│   ├── Service-Account-IAM.md
│   └── Workload-Identity-Map.md
│
├── 07 Compute
│   └── Compute-Assessment.md
│
├── 08 Network
│   └── Firewall-Matrix.md
│
├── 09 Storage
│   └── Cloud-Storage-Assessment.md
│
├── 10 Secrets
│   └── Secret-Manager-Assessment.md
│
├── 11 Serverless
│   └── Serverless-Assessment.md
│
├── 12 Logging
│   └── Logging-Assessment.md
│
├── 13 Attack Paths
│   └── Attack-Path-Register.md
│
├── 14 Evidence
│   └── Evidence-Register.md
│
├── 15 Findings
│   └── Findings-Register.md
│
├── 16 Report
│   └── Enterprise-GCP-Pentest-Report.md
│
└── 17 Retest
    └── Retest-Report.md

Phase 84 — Student Submission Checklist

ENGAGEMENT

[ ] Scope documented
[ ] Starting identity documented
[ ] Authorised projects documented
[ ] Rules of engagement understood
[ ] Stop conditions understood

ORGANISATION

[ ] Organisation hierarchy understood
[ ] Folders mapped where visible
[ ] Projects inventoried
[ ] Project boundaries understood

IAM

[ ] Project IAM reviewed
[ ] Relevant inherited IAM identified
[ ] Human identities mapped
[ ] Groups mapped
[ ] Roles reviewed
[ ] Custom roles reviewed where applicable
[ ] Effective permissions analysed

SERVICE ACCOUNTS

[ ] Service accounts inventoried
[ ] Workloads mapped to service accounts
[ ] Service account IAM reviewed
[ ] Service account usage relationships reviewed
[ ] Excessive permissions identified
[ ] Cross-project access reviewed
[ ] Long-lived credentials reviewed where applicable

COMPUTE

[ ] Compute instances inventoried
[ ] Public exposure reviewed
[ ] Service accounts identified
[ ] Administrative exposure reviewed
[ ] Workload-control relationships analysed

NETWORK

[ ] VPC architecture understood
[ ] Firewall rules reviewed
[ ] Internet exposure reviewed
[ ] Administrative paths reviewed
[ ] Segmentation considered

STORAGE

[ ] Buckets inventoried
[ ] Bucket IAM reviewed
[ ] Public access reviewed
[ ] Sensitive-data context considered
[ ] Cross-project access reviewed
[ ] Encryption/versioning considered

SECRETS

[ ] Secrets inventoried where authorised
[ ] Secret access IAM reviewed
[ ] Workload relationships reviewed
[ ] No unnecessary secret values collected

SERVERLESS

[ ] Serverless workloads inventoried
[ ] Invocation exposure reviewed
[ ] Service accounts reviewed
[ ] Deployment control reviewed
[ ] Sensitive-resource relationships analysed

LOGGING

[ ] Audit logging reviewed
[ ] Administrative activity visibility considered
[ ] IAM activity visibility considered
[ ] Sensitive-resource telemetry considered
[ ] Logging modification privilege reviewed

ATTACK PATHS

[ ] Hypotheses documented
[ ] Hypotheses separated from findings
[ ] Identity graph built
[ ] Workload identity paths analysed
[ ] Cross-project paths analysed
[ ] Minimum necessary validation followed
[ ] Remediation choke points identified

REPORTING

[ ] Evidence register completed
[ ] Findings register completed
[ ] Positive controls documented
[ ] Root causes identified
[ ] Remediation prioritised
[ ] Final report completed
[ ] Retest plan completed

Phase 85 — Skills You Should Demonstrate

After completing this project, you should be able to explain:

How do you begin a Google Cloud penetration test?

How does the Google Cloud resource hierarchy work?

How does IAM inheritance affect security?

Why must organisation, folder, project, and resource IAM be considered together?

What is a Google Cloud service account?

Why are service accounts important during penetration testing?

What is the security significance of service account impersonation?

How can workload control create indirect privilege?

How can cross-project IAM create attack paths?

How do you assess Compute Engine workload identity?

How do you evaluate Cloud Storage permissions?

How do you assess Secret Manager access?

How do serverless workloads interact with service accounts?

Why should long-lived service account credentials be minimised?

How do network exposure and workload identity combine to affect risk?

How do you build a GCP identity attack graph?

How do you safely validate a GCP privilege path?

Phase 86 — Interview Story

You should now be able to explain this project professionally:

In a CloudNova Google Cloud enterprise lab, I started with a low-privileged identity and mapped the organisation, projects, workloads, IAM bindings, and service accounts. I identified that a development identity could control an application workload using a service account with cross-project access to sensitive synthetic storage. I mapped the relationship from the human identity through workload control and service-account privilege into the data project, validated only the minimum evidence required, and documented the complete attack path. I recommended reducing the service account’s privilege, narrowing cross-project IAM, and separating workload administration from privileged machine identities.

This demonstrates:

Google Cloud IAM
       +
Service Account Security
       +
Workload Identity
       +
Cross-Project Trust
       +
Attack-Path Analysis
       +
Professional Reporting

Key Takeaways

Project 03 is about learning to think of Google Cloud as an interconnected identity, workload, and resource graph.

Remember:

Start with the active identity and project context.

Understand the resource hierarchy before analysing permissions.

IAM inheritance can make higher-level permissions more important than individual resource bindings.

Service accounts are security principals, not merely application configuration.

Always ask both who can use a service account and what that service account can do.

A developer may indirectly obtain higher privilege by controlling a workload using a powerful service account.

Cross-project IAM can create hidden enterprise attack paths.

Workload identity should be analysed together with workload control.

Static service account credentials increase credential-management risk.

Cloud Storage exposure must be evaluated in business context.

Secret access may represent an intermediate step toward another system.

Serverless workloads can carry powerful cloud identities.

Network exposure and identity privilege can combine to increase blast radius.

A hypothesis is not a validated finding.

Use the minimum necessary validation required to demonstrate risk.

Attack paths provide more security context than isolated permission findings.

Identify remediation choke points capable of breaking multiple paths.

Report security controls that worked as well as weaknesses.

Retest effective access—not merely changed configuration.

Your Google Cloud assessment methodology is:

Scope
  ↓
Establish Identity
  ↓
Map Organisation
  ↓
Map Folders
  ↓
Inventory Projects
  ↓
Inventory Resources
  ↓
Analyse IAM
  ↓
Analyse Inheritance
  ↓
Inventory Service Accounts
  ↓
Map Workload Identities
  ↓
Assess Compute
  ↓
Assess Network
  ↓
Assess Storage
  ↓
Assess Secrets
  ↓
Assess Serverless
  ↓
Assess Logging
  ↓
Analyse Cross-Project Trust
  ↓
Build Identity Graph
  ↓
Develop Hypotheses
  ↓
Validate Safely
  ↓
Build Attack Paths
  ↓
Collect Evidence
  ↓
Analyse Business Risk
  ↓
Recommend Controls
  ↓
Report
  ↓
Retest

What’s Next?

➡️ Project 04 — Kubernetes & Container Enterprise Compromise Assessment

You have now assessed the three major cloud platforms:

AWS
 ↓
IAM Roles & Workload Roles

Azure
 ↓
Entra ID & Managed Identities

Google Cloud
 ↓
IAM & Service Accounts

In Project 04, you will connect cloud security with the cloud-native application stack:

Application
    ↓
Container
    ↓
Pod
    ↓
Kubernetes Service Account
    ↓
Kubernetes RBAC
    ↓
Workload Identity
    ↓
Cloud IAM
    ↓
Sensitive Cloud Resource

You will assess:

Kubernetes cluster architecture
Namespaces
Pods and workloads
Containers
Kubernetes RBAC
Service accounts
Secrets
Pod security
Network policies
Container privilege
Workload identities
Cloud IAM integration
Logging and detection
Cross-layer attack paths

The core question becomes:

Can an application or container security weakness cross Kubernetes trust boundaries and ultimately reach privileged cluster or cloud resources?