09 — Enterprise Cloud Pentesting Projects

Welcome

Welcome to Module 09 — Enterprise Cloud Pentesting Projects.

You have now completed the major technical areas of the Cloud Penetration Tester learning path:

Cloud Offensive Security Foundations
AWS Cloud Penetration Testing
Azure Cloud Penetration Testing
Google Cloud Penetration Testing
Kubernetes Offensive Security
Container Security
Serverless Security
Cloud Red Team Operations

This module changes the learning model.

You are no longer going to study individual cloud security concepts in isolation.

You are going to operate as a Cloud Penetration Tester working through complete enterprise security engagements.

The objective is to connect:

Reconnaissance
      ↓
Cloud Asset Discovery
      ↓
Identity Enumeration
      ↓
Misconfiguration Analysis
      ↓
Privilege Path Discovery
      ↓
Controlled Validation
      ↓
Lateral Movement Analysis
      ↓
Critical Asset Impact
      ↓
Evidence Collection
      ↓
Risk Analysis
      ↓
Professional Reporting
      ↓
Remediation

These projects should be completed only within CloudNova or another explicitly authorised training environment.

Module Mission

Your mission is to complete five realistic enterprise Cloud Penetration Testing projects.

Each project introduces a different environment and security challenge.

By the end of the module, you should be able to move from:

“I understand individual cloud attacks.”

to:

“I can assess an enterprise cloud environment systematically, identify realistic attack paths, validate security weaknesses safely, document evidence, explain business impact, and produce professional remediation guidance.”

The Five Enterprise Projects

Project	Environment	Primary Focus
Project 01	AWS	Enterprise AWS Security Assessment
Project 02	Azure	Enterprise Azure Identity & Cloud Assessment
Project 03	Google Cloud	GCP IAM & Workload Security Assessment
Project 04	Kubernetes + Containers	Cloud-Native Application Compromise Assessment
Project 05	Multi-Cloud	Enterprise Cloud Red Team Capstone

The projects intentionally increase in complexity.

Project 01
Single Cloud
AWS
   ↓
Project 02
Single Cloud + Enterprise Identity
Azure
   ↓
Project 03
Cloud IAM + Workload Identity
GCP
   ↓
Project 04
Cloud-Native Infrastructure
Kubernetes + Containers
   ↓
Project 05
Multi-Cloud Enterprise
AWS + Azure + GCP + Kubernetes

Project 01 — Enterprise AWS Penetration Testing Assessment

Mission

You have been engaged to perform an authorised penetration test of a fictional organisation’s AWS environment hosted in CloudNova.

The organisation operates:

Internet
   ↓
Application Load Balancer
   ↓
EC2 Application Tier
   ↓
Database
   ↓
S3 Storage

Application
   ↓
IAM Role
   ↓
AWS Services

The security team wants to understand whether an attacker who gains limited access could expand their privileges or reach sensitive cloud resources.

Objectives

Assess:

AWS account exposure
IAM users and roles
IAM policies
Trust policies
EC2 security
Instance roles
Storage permissions
Network exposure
Secrets
Logging
Privilege relationships
Cross-service attack paths

Scenario

You begin with a low-privileged authorised CloudNova identity.

Your task is to determine:

What Can I See?
      ↓
What Can I Access?
      ↓
Which Identity Am I?
      ↓
What Permissions Exist?
      ↓
Which Trust Relationships Exist?
      ↓
Can Privilege Expand?
      ↓
Which Critical Assets Become Reachable?

Assessment Phases

Phase 1 — Scope Validation

Document:

AWS Account
Region
Authorised Identity
Allowed Services
Excluded Resources
Testing Restrictions
Stop Conditions

Phase 2 — Cloud Reconnaissance

Identify:

Account context
Regions
IAM identities
Compute resources
Storage
Databases
Networking
Serverless resources
Logging services

Create:

AWS Asset Inventory

Phase 3 — IAM Assessment

Review:

Users
 ↓
Groups
 ↓
Roles
 ↓
Policies
 ↓
Trust Relationships
 ↓
Effective Permissions

Look for security themes such as:

Excessive permissions
Broad resource permissions
Unnecessary role assumption
Weak trust relationships
Powerful workload identities
Privilege-changing permissions

Phase 4 — Compute Assessment

Review EC2 instances for:

Network exposure
Administrative access
Attached IAM roles
Security groups
Instance configuration
Workload trust

Phase 5 — Storage Assessment

Assess authorised lab storage for:

Public exposure
Excessive identity access
Cross-account access
Sensitive synthetic information
Logging
Encryption controls

Phase 6 — Attack-Path Analysis

Develop possible paths such as:

Low-Privilege Identity
        ↓
IAM Misconfiguration
        ↓
Workload Control
        ↓
Powerful Instance Role
        ↓
Sensitive S3 Resource

Validate only the minimum steps necessary to demonstrate the risk.

Phase 7 — Evidence

Capture:

AWS-ENV-001
AWS-IAM-001
AWS-IAM-002
AWS-EC2-001
AWS-S3-001
AWS-PATH-001

Phase 8 — Reporting

Produce:

Enterprise AWS Penetration Testing Report

Include:

Executive Summary
Scope
AWS Architecture
Methodology
Attack Surface
IAM Analysis
Validated Findings
Attack Paths
Evidence
Recommendations
Retest Plan

Project Deliverables

Project 01/
├── AWS Architecture Diagram
├── Asset Inventory
├── IAM Permission Map
├── Network Exposure Matrix
├── Attack Path Diagram
├── Evidence Register
├── Findings Register
└── AWS Penetration Testing Report

Project 02 — Enterprise Azure Identity & Cloud Penetration Test

Mission

CloudNova now places you inside a fictional enterprise Azure environment.

The organisation uses:

Microsoft Entra ID
        ↓
Azure Subscriptions
        ↓
Resource Groups
        ↓
Virtual Machines
        ↓
Applications
        ↓
Managed Identities
        ↓
Key Vault / Storage

This project focuses heavily on identity-driven cloud attack paths.

Objectives

Assess:

Entra identities
Azure RBAC
Role assignments
Managed identities
Resource groups
Virtual machines
Storage
Key Vault
Network controls
Administrative relationships
Privilege paths

Core Question

Do not simply ask:

Which Azure resources are vulnerable?

Ask:

Which identities can control which resources, and can those relationships eventually provide access to higher privilege or sensitive information?

Identity Mapping

Build:

User
 ↓
Entra Group
 ↓
Azure Role
 ↓
Scope
 ↓
Resource
 ↓
Managed Identity
 ↓
Additional Resources

Assessment Phases

Phase 1

Map tenant and subscription context.

Phase 2

Inventory authorised resources.

Phase 3

Analyse Entra identities and groups.

Phase 4

Analyse Azure RBAC.

Phase 5

Review managed identities.

Phase 6

Assess VM and network exposure.

Phase 7

Review Key Vault and storage security.

Phase 8

Build identity-driven attack paths.

Example:

Developer
   ↓
Can Modify Application
   ↓
Application Uses Managed Identity
   ↓
Managed Identity
   ↓
Key Vault Access
   ↓
Sensitive Application Secret

Phase 9

Determine remediation choke points.

For example:

Attack Path
    ↓
Excessive Developer Permission
    ↓
Remove Permission
    ↓
Path Broken

Project Deliverables

Project 02/
├── Azure Architecture Diagram
├── Entra Identity Map
├── Azure RBAC Matrix
├── Managed Identity Inventory
├── Key Vault Assessment
├── Network Exposure Matrix
├── Attack Path Diagram
├── Evidence Register
├── Findings Register
└── Azure Penetration Testing Report

Project 03 — Google Cloud IAM & Workload Security Assessment

Mission

Your third CloudNova engagement involves a fictional organisation running production workloads in Google Cloud.

Architecture:

Organisation
    ↓
Folders
    ↓
Projects
    ↓
IAM
    ↓
Compute / Serverless
    ↓
Service Accounts
    ↓
Storage / Databases

This project focuses on:

IAM inheritance and workload identity.

Objectives

Assess:

Organisation hierarchy
Projects
IAM bindings
Custom roles
Service accounts
Service account relationships
Compute workloads
Storage
Secrets
Serverless services
Logging
Privilege paths

Important Concept

Google Cloud access may inherit through:

Organisation
      ↓
Folder
      ↓
Project
      ↓
Resource

Therefore, do not review permissions only at the resource level.

Workload Identity Analysis

Build:

Human Identity
      ↓
Permission
      ↓
Workload
      ↓
Service Account
      ↓
Cloud Permission
      ↓
Sensitive Resource

Example Attack Path

Developer
    ↓
Controls Workload
    ↓
Workload Uses Service Account
    ↓
Service Account Has Excessive Permissions
    ↓
Sensitive Cloud Storage

Assessment Phases

Perform:

Environment Discovery
      ↓
Resource Inventory
      ↓
IAM Analysis
      ↓
Service Account Analysis
      ↓
Compute Assessment
      ↓
Storage Assessment
      ↓
Serverless Assessment
      ↓
Secret Management Review
      ↓
Attack Path Development
      ↓
Controlled Validation
      ↓
Reporting

Project Deliverables

Project 03/
├── GCP Architecture Diagram
├── Organisation Hierarchy Map
├── IAM Binding Matrix
├── Service Account Inventory
├── Workload Identity Map
├── Storage Assessment
├── Attack Path Diagram
├── Evidence Register
├── Findings Register
└── GCP Penetration Testing Report

Project 04 — Kubernetes & Container Enterprise Compromise Assessment

Mission

CloudNova provides an enterprise cloud-native application.

Architecture:

Internet
   ↓
Ingress
   ↓
Kubernetes Service
   ↓
Application Pod
   ↓
Kubernetes Service Account
   ↓
Cluster Permissions
   ↓
Cloud Workload Identity
   ↓
Cloud Resources

This project tests whether weaknesses across the application, container, Kubernetes, and cloud layers can combine into a meaningful attack path.

Objectives

Assess:

Container configuration
Kubernetes workloads
Namespaces
RBAC
Service accounts
Secrets
Network policies
Pod security
Workload identities
Cluster trust
Cloud integration
Logging and detection

Think Across Layers

Do not assess:

Container

Kubernetes

Cloud

as unrelated systems.

Assess:

Application
    ↓
Container
    ↓
Pod
    ↓
Service Account
    ↓
Kubernetes RBAC
    ↓
Cloud Identity
    ↓
Cloud Resource

Assessment Phases

Phase 1 — Architecture Mapping

Identify:

Cluster
Namespaces
Workloads
Services
Ingress
Service Accounts
RBAC
Secrets
Cloud Integration

Phase 2 — Container Review

Assess:

Runtime identity
Image configuration
Privileged settings
Mounted resources
Secrets exposure
Host interaction
Excessive capabilities

Phase 3 — Kubernetes RBAC

Build:

Subject
 ↓
Role
 ↓
Permission
 ↓
Resource
 ↓
Namespace

Phase 4 — Service Account Analysis

Determine:

Which Pod
   ↓
Uses Which Service Account
   ↓
With Which Permissions

Phase 5 — Network Segmentation

Assess:

Namespace A
     ↓
Allowed?
     ↓
Namespace B

and approved external/cloud destinations.

Phase 6 — Cloud Integration

Identify:

Kubernetes Identity
        ↓
Cloud Workload Identity
        ↓
Cloud Role
        ↓
Cloud Resource

Phase 7 — Enterprise Attack Path

Example:

Application Weakness
        ↓
Application Pod
        ↓
Kubernetes Service Account
        ↓
Excessive RBAC
        ↓
Additional Workload
        ↓
Cloud Workload Identity
        ↓
Sensitive Cloud Resource

The purpose is not to maximise compromise.

Stop when sufficient evidence demonstrates the risk.

Project Deliverables

Project 04/
├── Kubernetes Architecture Diagram
├── Namespace Inventory
├── Workload Inventory
├── RBAC Matrix
├── Service Account Map
├── Container Security Review
├── Network Policy Matrix
├── Cloud Identity Map
├── Attack Path Diagram
├── Evidence Register
├── Findings Register
└── Kubernetes Penetration Testing Report

Project 05 — Enterprise Multi-Cloud Red Team Capstone

Mission

This is the final CloudNova project.

You are now acting as a Cloud Penetration Tester on a complex enterprise engagement.

The fictional organisation operates:

Users
  ↓
Microsoft Entra ID
  ↓
Azure

Developers
  ↓
CI/CD
  ↓
AWS

Applications
  ↓
Kubernetes
  ↓
Cloud Workload Identities

Analytics
  ↓
Google Cloud

Your objective is to understand how trust relationships across these environments affect enterprise security.

This is not a collection of five separate penetration tests.

It is an enterprise attack-path assessment.

Capstone Architecture

                    Enterprise Identity
                           │
             ┌─────────────┼─────────────┐
             ↓             ↓             ↓
            AWS          Azure          GCP
             │             │             │
             └──────┐      │      ┌──────┘
                    ↓      ↓      ↓
                       CI/CD
                         ↓
                    Kubernetes
                         ↓
                      Workloads
                         ↓
                    Business Data

Capstone Objectives

Assess:

External cloud exposure
Enterprise identities
Cloud IAM
Cross-account trust
Cross-subscription relationships
Service accounts
Managed identities
Workload identities
CI/CD permissions
Kubernetes RBAC
Secrets
Cloud networking
Storage
Logging
Security monitoring
Attack paths

Phase 1 — Engagement Planning

Create:

Scope

Rules of Engagement

Testing Windows

Cloud Accounts

Subscriptions

Projects

Clusters

Approved Identities

Excluded Systems

Stop Conditions

Phase 2 — Architecture Discovery

Build a complete enterprise diagram.

Do not begin with exploitation.

Begin with:

What Exists?

Phase 3 — Asset Inventory

Create:

Asset	Platform	Identity	Exposure	Criticality
APP01	AWS	AppRole	Internet	High
KV01	Azure	Managed Identity	Internal	Critical
DATA01	GCP	Service Account	Internal	Critical
K8S01	Kubernetes	Workload Identity	Internal	High

Phase 4 — Identity Inventory

Map:

Human Identities

Service Accounts

Managed Identities

IAM Roles

Workload Identities

CI/CD Identities

Kubernetes Service Accounts

Phase 5 — Trust Mapping

Now connect them.

Developer
    ↓
Git Repository
    ↓
CI/CD
    ↓
Cloud Deployment Identity
    ↓
Kubernetes
    ↓
Workload Identity
    ↓
Cloud Resources

Phase 6 — Attack Surface Analysis

Analyse:

External Exposure

Administrative Exposure

Identity Exposure

Application Exposure

CI/CD Exposure

Container Exposure

Cloud API Exposure

Phase 7 — Hypothesis Development

Create:

ID	Hypothesis	Evidence Needed	Status
H-001	CI/CD identity may control production workload	IAM + pipeline	Open
H-002	Workload identity may access sensitive storage	IAM policy	Open
H-003	Developer may indirectly control privileged identity	Trust map	Open

Do not treat hypotheses as findings.

Phase 8 — Controlled Validation

Use the CloudNova lab to validate approved hypotheses.

For every validation:

Hypothesis
    ↓
Minimal Test
    ↓
Observation
    ↓
Evidence
    ↓
Stop

Phase 9 — Build Enterprise Attack Paths

Your final attack paths should connect multiple controls.

Example:

Developer Identity
       ↓
Excessive CI/CD Permission
       ↓
Deployment Pipeline
       ↓
Production Kubernetes Workload
       ↓
Workload Identity
       ↓
Cloud Role
       ↓
Sensitive Storage

Another:

Low-Privilege Cloud Identity
       ↓
Resource Modification
       ↓
Privileged Workload
       ↓
Managed Identity
       ↓
Secret Store
       ↓
Enterprise Application

Phase 10 — Identify Security Choke Points

Do not only ask:

How many vulnerabilities exist?

Ask:

Which control would break the greatest number of attack paths?

Example:

                    Excessive CI/CD Role
                           │
              ┌────────────┼────────────┐
              ↓            ↓            ↓
          Path 01       Path 02       Path 03

Reducing that privilege may eliminate multiple attack paths.

That is enterprise security thinking.

Phase 11 — Detection Analysis

For each validated path identify:

Attack Step
     ↓
Expected Log
     ↓
Security Telemetry
     ↓
Detection
     ↓
Alert
     ↓
Investigation

Document whether defensive visibility exists.

Phase 12 — Business Impact

Connect technical compromise to:

Sensitive Data

Production Systems

Customer Services

Administrative Control

Compliance

Business Operations

Avoid exaggeration.

Only claim what your evidence supports.

Phase 13 — Enterprise Findings

Your final report might contain findings such as:

CLOUD-001
CI/CD Deployment Identity Has Excessive Production Permissions

CLOUD-002
Workload Identity Provides Unnecessary Access to Sensitive Storage

CLOUD-003
Cloud Administrative Trust Is Broader Than Operationally Required

K8S-001
Application Service Account Has Excessive Cluster Permissions

IAM-001
Cloud Identity Governance Allows Indirect Privilege Escalation

Phase 14 — Attack Path Register

Create:

Path	Initial Access	Intermediate	Critical Asset	Risk
AP-01	Developer	CI/CD → K8s	Storage	Critical
AP-02	Cloud User	Workload	Secrets	High
AP-03	Application	Identity Chain	Production	High

Phase 15 — Evidence Register

Maintain:

EV-001
EV-002
EV-003
...

Every significant conclusion should trace back to evidence.

Evidence
    ↓
Finding
    ↓
Attack Path
    ↓
Business Risk

Phase 16 — Remediation Roadmap

Separate recommendations into:

Immediate

Remove Excessive Privileges

Rotate Exposed Lab Secrets

Restrict Administrative Exposure

Break Critical Trust Paths

Short Term

Improve IAM Governance

Harden Workload Identities

Strengthen Network Segmentation

Improve CI/CD Security

Implement Kubernetes Least Privilege

Strategic

Cloud Identity Governance

Zero Trust

Privileged Access Management

Continuous Cloud Security Monitoring

Attack-Path Management

Automated Policy Enforcement

Phase 17 — Retesting

After remediation:

Original Attack Path
        ↓
Control Changed
        ↓
Retest
        ↓
Can Path Still Succeed?

Record:

Resolved

Partially Resolved

Not Resolved

Final Capstone Deliverables

Project 05/
│
├── 01 Scope
│   ├── Scope Document
│   └── Rules of Engagement
│
├── 02 Architecture
│   ├── Enterprise Architecture
│   └── Trust Boundary Diagram
│
├── 03 Inventories
│   ├── Asset Inventory
│   ├── Identity Inventory
│   └── Cloud Resource Inventory
│
├── 04 IAM
│   ├── AWS IAM
│   ├── Azure RBAC
│   ├── GCP IAM
│   └── Kubernetes RBAC
│
├── 05 Attack Surface
│
├── 06 Hypotheses
│
├── 07 Evidence
│
├── 08 Findings
│
├── 09 Attack Paths
│
├── 10 Detection Analysis
│
├── 11 Remediation Roadmap
│
├── 12 Retest
│
└── 13 Final Report

Final Report

Your final deliverable should resemble a professional consulting engagement.

Enterprise Cloud Penetration Testing Report

1. Executive Summary

2. Engagement Objectives

3. Scope

4. Rules of Engagement

5. Environment Overview

6. Architecture

7. Methodology

8. Attack Surface

9. Identity & Access Analysis

10. Validated Findings

11. Enterprise Attack Paths

12. Business Impact

13. Detection Observations

14. Remediation Priorities

15. Strategic Recommendations

16. Conclusion

17. Technical Evidence

18. Retest Plan

Enterprise Project Progression

The five projects should progressively build your capability:

Project 01
AWS
 ↓
Understand Cloud IAM & Resource Security

Project 02
Azure
 ↓
Understand Enterprise Identity & Managed Identity

Project 03
GCP
 ↓
Understand Service Accounts & Workload Trust

Project 04
Kubernetes
 ↓
Understand Cloud-Native Attack Paths

Project 05
Multi-Cloud Capstone
 ↓
Understand Enterprise Trust Relationships

By Project 05 you should no longer think primarily in terms of:

AWS Vulnerability

Azure Vulnerability

Kubernetes Vulnerability

Instead think:

Identity
   ↓
Permission
   ↓
Trust
   ↓
Workload
   ↓
Another Identity
   ↓
Critical Resource

Project Assessment Standard

For every project, evaluate yourself across five areas.

Area	Expected Capability
Discovery	Identify relevant assets and identities
Analysis	Understand permissions and trust
Validation	Safely validate security hypotheses
Attack Paths	Connect weaknesses into realistic paths
Reporting	Explain evidence, impact and remediation

Use:

Level 1 — Requires Guidance

Level 2 — Can Perform With Checklist

Level 3 — Can Perform Independently

Level 4 — Can Explain and Defend Decisions

Your target by the end of this module should be:

Level 3 across the complete Cloud Penetration Testing workflow.

CloudNova Project Rules

All five projects must remain within the authorised CloudNova training environment.

Before every project:

[ ] Confirm CloudNova environment

[ ] Confirm authorised accounts

[ ] Confirm authorised identities

[ ] Confirm scope

[ ] Confirm excluded resources

[ ] Confirm permitted techniques

[ ] Confirm stop conditions

[ ] Use synthetic data only

[ ] Record evidence

[ ] Clean up changes

Never transfer CloudNova testing techniques directly to systems you do not own or have explicit permission to assess.

Portfolio Opportunity

These five projects can become the foundation of your Cloud Penetration Tester portfolio.

Your portfolio can demonstrate:

AWS Assessment
      +
Azure Assessment
      +
GCP Assessment
      +
Kubernetes Assessment
      +
Enterprise Multi-Cloud Capstone

For each project retain sanitised:

Architecture Diagram

Methodology

Asset Inventory

IAM Analysis

Attack Path Diagram

Example Finding

Remediation

Lessons Learned

Do not publish credentials, secrets, tokens, or restricted CloudNova environment information.

Final Skills Validation

After completing all five projects, you should be able to answer:

Can I scope a cloud penetration test?

Can I map an unfamiliar cloud environment?

Can I identify important cloud assets?

Can I analyse IAM?

Can I understand effective permissions?

Can I analyse workload identities?

Can I evaluate cloud trust relationships?

Can I assess AWS?

Can I assess Azure?

Can I assess GCP?

Can I assess Kubernetes?

Can I connect cloud and Kubernetes identities?

Can I analyse CI/CD trust?

Can I develop attack hypotheses?

Can I validate them safely?

Can I build enterprise attack paths?

Can I identify remediation choke points?

Can I collect professional evidence?

Can I explain business impact?

Can I write a professional penetration testing report?

Can I retest remediation?

If you can confidently demonstrate these capabilities in an authorised environment, you have moved significantly beyond simply knowing cloud security tools.

You are developing the methodology of a Cloud Penetration Tester.

Key Takeaways

Module 09 is where the previous modules come together.

Remember:

Enterprise cloud penetration testing is not vulnerability scanning.

Cloud attacks are frequently identity attacks.

Permissions must be analysed in context rather than individually.

Workload identities can connect application compromise with cloud privilege.

Kubernetes, containers, CI/CD, identity, and cloud infrastructure must be analysed as one connected system.

A hypothesis is not a finding until it is validated.

Use the minimum controlled action necessary to prove risk.

Every important conclusion should be supported by evidence.

Attack paths often provide more value than isolated vulnerability lists.

Identify security choke points that break multiple attack paths.

A professional Cloud Penetration Tester must understand remediation as well as offensive techniques.

The final deliverable is not the attack—it is the security improvement created from the assessment.

Your project progression is:

AWS
 ↓
Azure
 ↓
GCP
 ↓
Kubernetes + Containers
 ↓
Multi-Cloud Enterprise
 ↓
Attack Path Analysis
 ↓
Business Risk
 ↓
Professional Reporting

What’s Next?

➡️ 10 — Interview Preparation

You have now completed the practical technical journey of the Cloud Penetration Tester learning path.

In the next module, you will prepare to explain these skills during technical interviews.

You will practise questions covering:

Cloud penetration testing methodology
AWS security
Azure security
Google Cloud security
Kubernetes offensive security
Container security
Serverless security
IAM privilege analysis
Workload identities
Cloud networking
Cloud attack paths
Cloud red team concepts
Evidence and reporting
Scenario-based troubleshooting

Most importantly, you will learn how to answer questions using your five CloudNova projects as practical evidence.

Instead of saying:

“I have studied AWS penetration testing.”

you should be able to say:

“In an authorised enterprise AWS lab, I mapped the environment, analysed IAM and workload trust, developed a potential privilege path, validated the minimum required steps, documented the evidence, identified the root cause, and produced remediation recommendations.”

That transition—from knowledge to demonstrated experience—is the purpose of these five projects.