Project 04 — Kubernetes & Container Enterprise Compromise Assessment

Welcome

Welcome to Project 04 — Kubernetes & Container Enterprise Compromise Assessment.

In the previous projects, you assessed the identity and privilege models of the three major cloud platforms:

AWS
 ↓
IAM Users
IAM Roles
Workload Roles

Azure
 ↓
Microsoft Entra ID
Azure RBAC
Managed Identities

Google Cloud
 ↓
Cloud IAM
Service Accounts
Workload Identity

Project 04 moves deeper into the cloud-native application stack.

You will investigate what happens when an attacker gains control of:

Application
    ↓
Container
    ↓
Pod
    ↓
Kubernetes Identity
    ↓
Kubernetes RBAC
    ↓
Cluster Resources
    ↓
Workload Identity
    ↓
Cloud IAM
    ↓
Sensitive Cloud Resource

This is where application security, container security, Kubernetes security, and cloud IAM begin to converge.

Your objective is to answer:

Can compromise of an application or container cross Kubernetes trust boundaries and ultimately provide access to privileged cluster or cloud resources?

Mission Information

Project

Kubernetes & Container Enterprise Compromise Assessment

Platform

CloudNova

Difficulty

Advanced

Estimated Time

5–7 hours

Primary Skills

• Kubernetes reconnaissance

• Cluster architecture analysis

• Namespace discovery

• Workload enumeration

• Container security assessment

• Kubernetes RBAC analysis

• Service account analysis

• Kubernetes Secrets review

• Pod security assessment

• NetworkPolicy analysis

• Container privilege analysis

• Workload identity assessment

• Cloud IAM correlation

• Attack-path development

• Evidence collection

• Enterprise reporting

Mission Objective

A fictional organisation operates a Kubernetes-based application environment inside CloudNova.

The environment resembles:

                         Internet
                            │
                            ↓
                      Load Balancer
                            │
                            ↓
                         Ingress
                            │
                    ┌───────┴───────┐
                    ↓               ↓
                 Web Pod          API Pod
                    │               │
                    └───────┬───────┘
                            ↓
                        Data Layer

However, workloads also interact with Kubernetes and cloud identities:

Application
    ↓
Container
    ↓
Pod
    ↓
Kubernetes Service Account
    ↓
Kubernetes RBAC
    ↓
Kubernetes API

and potentially:

Pod
 ↓
Workload Identity
 ↓
Cloud IAM Role / Managed Identity / Service Account
 ↓
Cloud Resource

The organisation is concerned about:

• Overprivileged Kubernetes service accounts

• Excessive Kubernetes RBAC

• Privileged containers

• Dangerous pod configurations

• Weak namespace isolation

• Excessive Secrets exposure

• Missing NetworkPolicies

• Workload identity privilege

• Cloud IAM integration

• Weak container hardening

• Excessive cluster administrative access

• Poor logging and detection

Your mission is to determine whether these weaknesses combine into meaningful enterprise compromise paths.

Starting Position

You begin with authorised access to the CloudNova Kubernetes training environment.

Example:

Cluster:
cloudnova-enterprise

Starting Context:
cloudnova-student

Namespace:
development

Privilege:
Limited

Objective:
Determine whether application, container,
Kubernetes, identity, and cloud relationships
create unintended privilege paths.

Rules of Engagement

Allowed:

Cluster discovery

Namespace enumeration

Workload enumeration

RBAC review

Service account review

Pod security review

Container configuration review

Secrets permission analysis

NetworkPolicy review

Workload identity analysis

Cloud IAM relationship analysis

Controlled security validation

Evidence collection

Not allowed unless explicitly required by CloudNova:

Denial of Service

Deleting workloads

Deleting namespaces

Deleting Secrets

Disabling security controls

Disrupting cluster networking

Deploying persistent unauthorised access

Attacking unrelated clusters

Testing third-party infrastructure

Accessing unnecessary sensitive data

Golden Rule

Follow:

Minimum Necessary Validation

Your goal is to demonstrate the attack path.

Your goal is not to maximise cluster damage.

Project Success Criteria

By the end of the project, produce:

Kubernetes Architecture Diagram

Namespace Inventory

Workload Inventory

Container Security Assessment

Kubernetes RBAC Matrix

Service Account Inventory

Secrets Access Matrix

Pod Security Assessment

NetworkPolicy Assessment

Workload Identity Map

Cloud IAM Relationship Map

Attack Path Register

Evidence Register

Findings Register

Enterprise Kubernetes Security Report

Phase 01 — Prepare Your Project Workspace

Create:

Project 04 - Kubernetes Enterprise Assessment/
│
├── 01 Engagement
├── 02 Architecture
├── 03 Cluster Discovery
├── 04 Namespaces
├── 05 Workloads
├── 06 Containers
├── 07 RBAC
├── 08 Service Accounts
├── 09 Secrets
├── 10 Pod Security
├── 11 Network Security
├── 12 Workload Identity
├── 13 Cloud IAM
├── 14 Logging
├── 15 Attack Paths
├── 16 Evidence
├── 17 Findings
├── 18 Report
└── 19 Retest

Inside 01 Engagement create:

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

Phase 02 — Document Scope

Record:

Platform:
Kubernetes

Environment:
CloudNova

Cluster:
<CLUSTER>

Starting Context:
<CONTEXT>

Authorised Namespaces:
<NAMESPACES>

Cloud Platform:
<AWS / AZURE / GCP / LAB>

In Scope:
Cluster Configuration
Namespaces
Pods
Deployments
Containers
RBAC
Service Accounts
Secrets Permissions
NetworkPolicies
Workload Identity
Approved Cloud Resources

Out of Scope:
Other Clusters
Third-Party Infrastructure
DoS
Destructive Operations
Unapproved Cloud Accounts

Phase 03 — Confirm Kubernetes Context

Before interacting with the cluster, determine:

Which cluster am I connected to?

Use:

kubectl config current-context

Review available contexts:

kubectl config get-contexts

Do not switch to or interact with clusters outside CloudNova scope.

Phase 04 — Record Cluster Context

Create:

Field	Value
Cluster	cloudnova-enterprise
Context	cloudnova-student
Starting Namespace	development
Starting Identity	<identity>
Cloud Platform	<platform>
Effective Privilege	Unknown

Again:

Effective Privilege:
Unknown

That is one of the main things you will determine.

Phase 05 — Understand Kubernetes Architecture

Before testing, understand the basic architecture:

                    Kubernetes Cluster
                           │
            ┌──────────────┴──────────────┐
            ↓                             ↓
      Control Plane                  Worker Nodes
            │                             │
      API Server                     kubelet
      Scheduler                          │
      Controllers                        ↓
      etcd                         Pods / Containers

The Kubernetes API server is the central security control point.

Conceptually:

User / Workload
       ↓
Authentication
       ↓
Kubernetes API
       ↓
Authorization
       ↓
Admission Control
       ↓
Resource

Phase 06 — Discover Cluster Information

Start with:

kubectl cluster-info

Then:

kubectl version

Record:

Cluster

Control Plane Endpoint

Client Version

Server Version

Authorised Context

Do not treat version information alone as a vulnerability.

Phase 07 — Discover Nodes

Where authorised:

kubectl get nodes

For more information:

kubectl get nodes -o wide

Create:

Node	Role	Version	Internal IP	External IP
worker01	Worker	<version>	10.10.1.10	None
worker02	Worker	<version>	10.10.1.11	None

Phase 08 — Discover Namespaces

Use:

kubectl get namespaces

Possible environment:

default

development

production

monitoring

security

kube-system

Create:

Namespace	Purpose	Criticality	Accessible?
development	Development	Medium	Yes
production	Production	Critical	Review
monitoring	Monitoring	High	Review
security	Security tooling	Critical	Review
kube-system	Cluster services	Critical	Review

Phase 09 — Namespace Security Boundaries

Namespaces provide organisational and policy boundaries.

But remember:

A namespace is not automatically a complete security boundary.

Effective isolation depends on:

RBAC

NetworkPolicies

Pod Security

Secrets Access

Workload Identity

Resource Configuration

Phase 10 — Discover Workloads

For your authorised namespace:

kubectl get pods

Then:

kubectl get deployments

and where permitted:

kubectl get services

Build:

Workload	Type	Namespace	Service Account	Exposure
web-app	Deployment	development	web-sa	Ingress
api-app	Deployment	development	api-sa	Internal
worker	Deployment	development	worker-sa	Internal

Phase 11 — Expand the Inventory

Where authorised:

kubectl get pods,deployments,services -n development

For a broader approved inventory:

kubectl get pods -A

Only use cluster-wide enumeration where your supplied permissions and CloudNova scope allow it.

Phase 12 — Inspect a Pod

Use:

kubectl describe pod <POD-NAME> -n <NAMESPACE>

Record:

Namespace

Container Images

Service Account

Volumes

Environment Sources

Security Context

Node

Network Information

Do not copy sensitive values unnecessarily.

Phase 13 — Workload Architecture Map

Build:

Ingress
   ↓
web-app
   ↓
web-sa
   │
   ↓
api-app
   ↓
api-sa
   │
   ↓
Data Services

Then add Kubernetes permissions.

Phase 14 — Container Image Review

For each workload identify:

Image Registry

Image Name

Tag

Digest

Image Source

Runtime User

Ask:

Is :latest Used?

Is the Image Trusted?

Is It Signed?

Is It Scanned?

Does It Run as Root?

Is the Image Larger Than Necessary?

Are Unnecessary Tools Installed?

Phase 15 — Container Security Model

Think:

Container Image
      ↓
Runtime Configuration
      ↓
Linux Process
      ↓
Container Isolation
      ↓
Host Kernel

Containers do not provide the same isolation boundary as independent virtual machines.

Phase 16 — Container Runtime Identity

Review:

runAsUser

runAsGroup

runAsNonRoot

privileged

allowPrivilegeEscalation

Example secure direction:

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false

The exact configuration depends on application requirements.

Phase 17 — Privileged Containers

A privileged container can significantly weaken isolation.

Security question:

Does This Workload Need
Privileged Host-Level Capability?

If not:

Remove Privileged Mode

Do not attempt destructive host escape techniques.

Configuration evidence may already be sufficient to demonstrate risk.

Phase 18 — Linux Capabilities

Containers may receive additional Linux capabilities.

Review:

Added Capabilities

Dropped Capabilities

Application Requirement

Secure direction:

Drop Unnecessary Capabilities

Ideally:

Drop ALL
   ↓
Add Only Required

where compatible with the workload.

Phase 19 — Host Namespace Sharing

Review whether pods use:

hostNetwork

hostPID

hostIPC

These settings can reduce isolation.

Ask:

Why does the workload require access to the host namespace?

Phase 20 — HostPath Volumes

Pay particular attention to:

hostPath

Conceptually:

Container
   ↓
HostPath
   ↓
Node Filesystem

This can create a powerful trust relationship.

Do not modify host files during the assessment.

Phase 21 — Writable Host Mounts

A writable host mount can represent significantly more risk than a read-only application volume.

Document:

Mount Path

Host Path

Read/Write

Business Requirement

Workload Privilege

Phase 22 — Kubernetes Service Accounts

Every pod operates in a Kubernetes identity context.

Conceptually:

Pod
 ↓
Kubernetes Service Account
 ↓
RBAC
 ↓
Kubernetes API

This identity must be mapped for every important workload.

Phase 23 — Inventory Service Accounts

Use:

kubectl get serviceaccounts -n <NAMESPACE>

Where authorised across the cluster:

kubectl get serviceaccounts -A

Create:

Service Account	Namespace	Workload	RBAC	Cloud Identity
web-sa	development	web-app	Limited	web-role
api-sa	development	api-app	Review	api-role
deploy-sa	development	CI/CD	Elevated	deployment-role

Phase 24 — Default Service Account

Check whether workloads unnecessarily use:

default

Example:

Pod
 ↓
default ServiceAccount

Dedicated service accounts make:

Least Privilege

Auditability

Workload Separation

easier to implement.

Phase 25 — Token Automounting

Determine whether workloads require automatic service account credentials.

Conceptually:

Pod
 ↓
Service Account Credential
 ↓
Kubernetes API

If the application never needs Kubernetes API access, ask:

Does it need this identity credential available inside the pod?

Phase 26 — Kubernetes RBAC

RBAC uses:

Subject
   ↓
Role / ClusterRole
   ↓
RoleBinding / ClusterRoleBinding
   ↓
Permissions

This is the Kubernetes equivalent of a major identity graph.

Phase 27 — Discover Roles

Where authorised:

kubectl get roles -A

and:

kubectl get clusterroles

Do not assume that every ClusterRole is dangerous.

Understand how it is bound.

Phase 28 — Discover Bindings

Use:

kubectl get rolebindings -A

and where authorised:

kubectl get clusterrolebindings

Build:

Subject
 ↓
Binding
 ↓
Role
 ↓
Permission
 ↓
Resource

Phase 29 — RBAC Permission Analysis

For each important role analyse:

apiGroups

resources

verbs

resourceNames

namespace / cluster scope

Important verbs may include:

get

list

watch

create

update

patch

delete

The security significance depends on the resource being controlled.

Phase 30 — Check Effective Permissions

For your current authorised identity:

kubectl auth can-i --list

For specific questions:

kubectl auth can-i get pods -n development

or:

kubectl auth can-i list secrets -n development

This is extremely useful because it answers:

What can this identity actually do?

Phase 31 — RBAC Matrix

Create:

Subject	Permission	Resource	Scope	Security Question
student	get/list	pods	development	Recon
student	update	deployments	development	Workload control?
web-sa	get	configmaps	development	Required
api-sa	get	secrets	development	Excessive?

Phase 32 — Wildcard Permissions

Review carefully:

verbs:
  - "*"

or:

resources:
  - "*"

But do not report wildcards without context.

Ask:

Which Subject?

Which Scope?

Which Resources?

Why Is It Required?

What Attack Path Does It Enable?

Phase 33 — Cluster-Level Permissions

Cluster-wide RBAC deserves particular attention.

Conceptually:

Service Account
      ↓
ClusterRoleBinding
      ↓
Broad Cluster Permission

If a normal application workload possesses cluster-wide control, investigate carefully.

Phase 34 — RBAC Hypothesis

Suppose:

student
   ↓
Can Update Deployment
   ↓
api-app

and:

api-app
   ↓
api-sa

and:

api-sa
   ↓
Can Read Selected Secrets

Potential hypothesis:

student
   ↓
Workload Control
   ↓
api-app
   ↓
api-sa
   ↓
Secret Access

Do not immediately modify the deployment.

First determine whether configuration evidence sufficiently demonstrates the relationship.

Phase 35 — Create the Hypothesis Register

ID	Hypothesis	Evidence	Status
K8S-H-001	Developer can indirectly use api-sa	Deployment + RBAC	Investigate
K8S-H-002	api-sa has excessive secret access	Role	Investigate
K8S-H-003	Web pod may reach data namespace	NetworkPolicy	Investigate
K8S-H-004	Workload identity may access cloud secrets	Cloud IAM	Investigate

Phase 36 — Kubernetes Secrets

Inventory only where authorised:

kubectl get secrets -n <NAMESPACE>

Start with metadata.

Do not retrieve secret values unnecessarily.

Phase 37 — Secrets Security Questions

Ask:

Which Secrets Exist?

Which Workloads Need Them?

Which Service Accounts Can Read Them?

Who Can Modify Them?

Are Secrets Shared Across Applications?

Are Secrets Synced From External Secret Stores?

Are Sensitive Values Exposed Through Environment Variables?

Phase 38 — Secret Access Is Not the Final Impact

Example:

Compromised Pod
      ↓
Kubernetes Secret
      ↓
Database Credential
      ↓
Database

or:

Compromised Pod
      ↓
Cloud Credential
      ↓
Cloud IAM
      ↓
Sensitive Resource

Always understand what the secret protects.

Phase 39 — Secret Handling

Do not place actual sensitive values in:

Screenshots

Reports

Shared Notes

Ticketing Systems

Git Repositories

Use:

REDACTED

or evidence that proves access without reproducing the value.

Phase 40 — ConfigMaps

ConfigMaps are not intended for secret storage.

Review whether they contain:

Passwords

Tokens

API Keys

Private Credentials

Connection Strings With Secrets

If they do, document the security design issue.

Phase 41 — Environment Variables

Inspect workload definitions for references to:

env

envFrom

secretKeyRef

configMapKeyRef

The question is:

Is sensitive configuration delivered to only the workloads that require it?

Phase 42 — Pod Security

Assess workload security contexts for:

runAsNonRoot

allowPrivilegeEscalation

privileged

capabilities

seccompProfile

readOnlyRootFilesystem

hostNetwork

hostPID

hostIPC

hostPath

Phase 43 — Pod Security Standards

Think in terms of progressively stronger controls such as:

Privileged

Baseline

Restricted

Your task is not simply to assign a label.

Determine whether workload configuration matches its actual risk.

Phase 44 — Admission Controls

Enterprise clusters may enforce workload security through mechanisms such as:

Pod Security Admission

OPA Gatekeeper

Kyverno

Cloud Provider Policies

Ask:

Are Security Policies Enforced?

Which Namespaces?

Can Developers Bypass Them?

Are Exceptions Documented?

Phase 45 — Deployment Security Review

Inspect:

kubectl get deployment <DEPLOYMENT> \
  -n <NAMESPACE> \
  -o yaml

Review:

Image

Service Account

Security Context

Volumes

Environment Sources

Resource Limits

Probes

Labels

Selectors

Avoid storing sensitive values from the output.

Phase 46 — Resource Limits

Review whether workloads define:

CPU Requests

Memory Requests

CPU Limits

Memory Limits

This is primarily resilience and resource-governance related, but it forms part of secure workload configuration.

Phase 47 — Image Pull Policy

Review:

imagePullPolicy

and image-tagging practices.

Prefer deterministic deployment practices over uncontrolled mutable images.

Phase 48 — Image Registry Security

Ask:

Where Are Images Stored?

Who Can Push?

Who Can Pull?

Are Images Scanned?

Are Images Signed?

Are Production Images Immutable?

Can Developers Replace Trusted Images?

This introduces a supply-chain attack path.

Phase 49 — Container Supply Chain Path

Example:

Developer
   ↓
Registry Push
   ↓
Trusted Image
   ↓
Production Deployment
   ↓
Privileged Workload

This may be more important than an individual container vulnerability.

Phase 50 — NetworkPolicies

List:

kubectl get networkpolicies -A

Ask:

Which Namespaces Have Policies?

Is Default-Deny Used?

Which Pods Can Communicate?

Is Egress Restricted?

Can Development Reach Production?

Can Application Pods Reach Management Services?

Phase 51 — Network Segmentation Model

Without adequate controls:

Compromised Pod
      ↓
Other Pods
      ↓
Internal Services
      ↓
Sensitive Systems

With intentional segmentation:

Web Pod
  ↓
API Pod
  ↓
Database

Other Paths
   X

Phase 52 — Build a Kubernetes Network Matrix

Create:

Source	Destination	Port	Expected	Observed
Ingress	web-app	443	Allow	Allow
web-app	api-app	8080	Allow	Allow
web-app	database	5432	Deny	Review
development	production	Any	Deny	Review
app	metadata/cloud APIs	Required only	Review	Review

Phase 53 — Egress Security

Do not focus only on inbound traffic.

A compromised workload may attempt to reach:

Internal APIs

Cloud APIs

Metadata Services

Databases

External Services

Therefore ask:

Where can this pod initiate connections?

Phase 54 — Kubernetes DNS

Internal service discovery often uses Kubernetes DNS.

Conceptually:

Pod
 ↓
DNS
 ↓
Service Name
 ↓
Internal Application

Network segmentation should account for internal service discovery.

Phase 55 — Ingress Security

Review:

Ingress Resources

TLS

Hostnames

Backend Services

Authentication

Administrative Endpoints

Public exposure must be intentional.

Phase 56 — Workload Identity

Now connect Kubernetes to cloud IAM.

Modern managed Kubernetes environments may use mechanisms such as:

AWS
 ↓
Pod Identity / IAM Integration

Azure
 ↓
Microsoft Entra Workload Identity

Google Cloud
 ↓
Workload Identity Federation

The exact implementation depends on the CloudNova project.

Phase 57 — Identity Layers

A pod may have multiple identity contexts:

Container Process Identity
        ↓
Kubernetes Service Account
        ↓
Workload Identity
        ↓
Cloud IAM Identity

Each layer must be understood.

Phase 58 — Workload Identity Map

Create:

Pod	K8s SA	Cloud Identity	Cloud Permission	Critical Resource
web-app	web-sa	web-role	Storage Read	Assets
api-app	api-sa	app-role	Secret Read	App Secret
worker	worker-sa	processor-role	Queue/Data	Processing

Phase 59 — Cloud IAM Questions

For every workload identity ask:

Which Kubernetes Service Account Maps to It?

Which Namespace?

Which Workloads Can Use That Service Account?

What Cloud Permissions Exist?

Which Cloud Resources Are Reachable?

Can the Cloud Identity Assume Another Identity?

Who Can Modify the Kubernetes Workload?

Phase 60 — Cross-Layer Attack Path

Suppose:

Developer
   ↓
Can Modify api-app
   ↓
api-app
   ↓
api-sa
   ↓
Cloud Workload Identity
   ↓
Secret Manager

Potential path:

Developer
   ↓
Kubernetes Workload Control
   ↓
Kubernetes Identity
   ↓
Cloud Identity
   ↓
Cloud Secret

This is one of the most important patterns in the entire project.

Phase 61 — Kubernetes-to-AWS Example

Conceptually:

Pod
 ↓
Kubernetes Service Account
 ↓
AWS Workload Identity
 ↓
IAM Role
 ↓
S3 / Secrets Manager

Assess:

K8s Identity Scope

IAM Trust

IAM Permissions

Resource Scope

Phase 62 — Kubernetes-to-Azure Example

Conceptually:

Pod
 ↓
Kubernetes Service Account
 ↓
Workload Federation
 ↓
Managed / Application Identity
 ↓
Azure RBAC
 ↓
Key Vault / Storage

Phase 63 — Kubernetes-to-GCP Example

Conceptually:

Pod
 ↓
Kubernetes Service Account
 ↓
Workload Identity
 ↓
Google Cloud Service Account / Principal
 ↓
Cloud IAM
 ↓
Secret Manager / Storage

Phase 64 — Cloud Identity Is a Privilege Boundary

Never assume:

Pod Compromise

ends at Kubernetes.

It may become:

Pod Compromise
      ↓
Cloud Identity
      ↓
Cloud Resource Access

This is why cloud and Kubernetes assessments should not be performed in isolation.

Phase 65 — Node Security

Review node architecture conceptually:

Worker Node
│
├── kubelet
├── Container Runtime
├── Pod A
├── Pod B
└── Pod C

Ask:

Are Nodes Dedicated?

Are Sensitive Workloads Separated?

Are Node Images Hardened?

Are Nodes Patched?

Are Management Interfaces Restricted?

Phase 66 — Node Access

Node-level administrative access is highly privileged.

Determine:

Who Can Administer Nodes?

How Is Access Authenticated?

Is Access Logged?

Are Nodes Publicly Reachable?

Are Administrative Paths Restricted?

Phase 67 — Kubernetes API Exposure

Review:

API Endpoint Exposure

Public vs Private

Authorised Networks

Authentication

RBAC

Audit Logging

A public control-plane endpoint is not automatically a vulnerability.

The entire control set must be considered.

Phase 68 — etcd Security

Conceptually:

Kubernetes API
      ↓
etcd
      ↓
Cluster State

etcd contains highly sensitive cluster state.

Assess architecture and controls such as:

Network Restriction

Encryption

Authentication

Backup Security

Do not directly access etcd unless CloudNova specifically provides an isolated exercise for it.

Phase 69 — Secrets Encryption

Kubernetes Secrets are not magically protected merely because the resource type is named Secret.

Review whether the environment provides appropriate:

Encryption at Rest

KMS Integration

RBAC

External Secret Management

Phase 70 — External Secret Stores

Enterprise environments may use:

AWS Secrets Manager

Azure Key Vault

Google Secret Manager

HashiCorp Vault

with Kubernetes.

This creates:

Pod
 ↓
Workload Identity
 ↓
External Secret Store

Assess both sides of the trust relationship.

Phase 71 — CI/CD Relationships

Kubernetes environments frequently depend on:

Git Repository
      ↓
CI/CD
      ↓
Container Registry
      ↓
Deployment
      ↓
Kubernetes

Ask:

Who Can Change Deployment Manifests?

Who Can Push Images?

Who Can Deploy to Production?

Which CI/CD Identity Is Used?

What Kubernetes Permissions Does It Have?

What Cloud Permissions Does It Have?

Phase 72 — CI/CD Attack Path

Example:

Developer
   ↓
Pipeline Control
   ↓
Deployment Identity
   ↓
Kubernetes Production
   ↓
Privileged Workload

This can be an enterprise attack path even if the cluster itself is well hardened.

Phase 73 — Kubernetes Attack Surface Map

Your map may now resemble:

Internet
   │
   ↓
Ingress
   │
   ↓
web-app
   │
   ├── web-sa
   │
   ↓
api-app
   │
   ├── api-sa
   │
   ↓
Data Service

Kubernetes API
   ↑
   │
RBAC
   ↑
   │
Users / Service Accounts

Cloud IAM
   ↑
   │
Workload Identity
   ↑
   │
api-sa

Phase 74 — Build the Identity Graph

Example:

developer
   │
   └── Deployment Update
            ↓
         api-app
            ↓
          api-sa
            │
            ├── Kubernetes Secret Read
            │
            └── Cloud Workload Identity
                        ↓
                    app-role
                        ↓
                  Cloud Secret

Now you can see the complete enterprise relationship.

Phase 75 — Attack Path 01

Developer → Workload → Kubernetes Service Account → Secret

Developer
   ↓
Deployment Modification
   ↓
API Workload
   ↓
api-sa
   ↓
Secret Read Permission
   ↓
Sensitive Application Secret

Document every transition.

Phase 76 — Attack Path 02

Container → Excessive RBAC → Cluster Resources

Compromised Application
        ↓
Container
        ↓
Service Account
        ↓
Broad Kubernetes RBAC
        ↓
Sensitive Cluster Resource

Phase 77 — Attack Path 03

Pod → Workload Identity → Cloud Resource

Compromised Pod
      ↓
Kubernetes Service Account
      ↓
Cloud Workload Identity
      ↓
Cloud IAM
      ↓
Sensitive Storage / Secret

Phase 78 — Attack Path 04

Developer → Container Registry → Production Workload

Developer
   ↓
Registry Write
   ↓
Production Image
   ↓
Production Deployment
   ↓
Privileged Workload Identity

This demonstrates why supply-chain permissions matter.

Phase 79 — Attack Path 05

Namespace → Missing Network Isolation → Sensitive Service

Compromised Development Pod
           ↓
Missing / Weak NetworkPolicy
           ↓
Production-Like Service
           ↓
Sensitive Application

Phase 80 — Attack Path Register

Create:

ID	Start	Transition	Target	Status	Risk
K8S-AP-001	Developer	Workload → api-sa	Secret	Validated	High
K8S-AP-002	Pod	Broad RBAC	Cluster Resource	Investigate	TBD
K8S-AP-003	Pod	Workload Identity	Cloud Secret	Validated	Critical/High
K8S-AP-004	Developer	Registry → Deployment	Privileged Workload	Investigate	TBD
K8S-AP-005	Dev Pod	Network Path	Sensitive Service	Validated	High

Phase 81 — Identify Choke Points

Potential remediation choke points:

Developer Deployment Permission

api-sa Kubernetes RBAC

Workload Identity Mapping

Cloud IAM Role

NetworkPolicy

Registry Write Permission

Example:

Attack Path 01 ──┐
                 │
Attack Path 02 ──┼──→ api-sa
                 │
Attack Path 03 ──┘

Reducing api-sa privilege may break several attack paths simultaneously.

Phase 82 — Controlled Validation Decision

For every path:

Security Hypothesis
       ↓
Configuration Evidence
       ↓
Enough?
  ┌────┴────┐
 Yes        No
 ↓          ↓
Stop     Safe Test?
          │
       ┌──┴──┐
      Yes    No
       ↓      ↓
 Minimal   Document
 Test      Potential Risk
       ↓
   Evidence
       ↓
      Stop

Phase 83 — Evidence Collection

Use evidence IDs:

K8S-EV-001
Cluster context

K8S-EV-002
Namespace inventory

K8S-EV-003
Workload inventory

K8S-EV-004
Service account mapping

K8S-EV-005
Role definition

K8S-EV-006
Role binding

K8S-EV-007
Pod security configuration

K8S-EV-008
NetworkPolicy configuration

K8S-EV-009
Workload identity relationship

K8S-EV-010
Cloud IAM permission

K8S-EV-011
Controlled validation

Phase 84 — Evidence Template

Evidence ID:
K8S-EV-009

Timestamp:
<DATE/TIME>

Cluster:
cloudnova-enterprise

Namespace:
development

Workload:
api-app

Observation:
The workload uses Kubernetes service account api-sa,
which maps to a cloud workload identity.

Security Relevance:
The mapped cloud identity can access a sensitive
synthetic secret outside the application's expected requirement.

Attack Path:
K8S-AP-003

Sensitive Data Collected:
None

Phase 85 — Finding Example 01

K8S-001 — Application Workload Uses an Overprivileged Kubernetes Service Account

Observation

An application workload operates using a Kubernetes service account with permissions beyond its documented operational requirements.

Attack Scenario

Compromise of the application could provide an attacker with access to the service account’s effective Kubernetes permissions.

Impact

The attacker may be able to interact with sensitive cluster resources beyond the application’s intended boundary.

Root Cause

Insufficient workload-specific RBAC.

Recommendation

Assign a dedicated service account and restrict its RBAC permissions to the minimum resources and verbs required.

Phase 86 — Finding Example 02

K8S-002 — Developer Workload Control Creates an Indirect Privilege Path

Observation

A development identity can modify a workload operating under a more privileged Kubernetes service account.

Attack Scenario

Compromise of the development identity could allow the attacker to influence a workload with higher Kubernetes privileges than those granted directly to the developer.

Root Cause

Insufficient separation between workload administration and workload identity privilege.

Recommendation

Restrict modification of privileged workloads and separate development responsibilities from privileged Kubernetes identities.

Phase 87 — Finding Example 03

K8S-003 — Kubernetes Workload Identity Has Excessive Cloud IAM Permissions

Observation

A Kubernetes workload identity maps to a cloud identity possessing permissions beyond the workload’s documented requirements.

Attack Scenario

Compromise of the pod could potentially extend beyond the Kubernetes cluster into sensitive cloud resources.

Impact

This weakness increases the blast radius from application compromise to cloud control-plane or data-plane access.

Recommendation

Restrict the cloud identity to workload-specific resources and operations.

Phase 88 — Finding Example 04

K8S-004 — Container Runs With Excessive Runtime Privilege

Observation

A workload uses container security settings that provide privileges beyond those required by the application.

Risk

Excessive runtime privilege weakens container isolation and increases the impact of an application compromise.

Recommendation

Run the workload as a non-root user, disable unnecessary privilege escalation, remove unnecessary Linux capabilities, and avoid privileged mode.

Phase 89 — Finding Example 05

K8S-005 — Namespace Lacks Effective Network Isolation

Observation

Workloads in the assessed namespace can establish network connections beyond documented application requirements.

Impact

Compromise of one workload may provide unnecessary access to other internal services.

Recommendation

Implement default-deny NetworkPolicies and explicitly permit only required application flows.

Phase 90 — Finding Example 06

K8S-006 — Sensitive Information Stored in ConfigMap

Observation

Sensitive application configuration is stored in a Kubernetes ConfigMap rather than an approved secret-management mechanism.

Impact

Users or workloads with ordinary ConfigMap read permissions may gain access to sensitive configuration.

Recommendation

Move sensitive values to Kubernetes Secrets or preferably the organisation’s approved external secret-management platform, with tightly scoped access.

Phase 91 — Finding Example 07

K8S-007 — Workload Uses Default Service Account Without Business Requirement

Observation

An application uses the namespace’s default Kubernetes service account despite not requiring Kubernetes API interaction.

Risk

Unnecessary workload credentials increase the potential impact of application compromise.

Recommendation

Use a dedicated least-privilege service account and disable unnecessary automatic credential mounting.

Phase 92 — Finding Example 08

K8S-008 — Container Registry Permissions Permit Excessive Image Modification

Observation

A broad development identity can modify container images used by higher-value workloads.

Attack Scenario

Compromise of the development identity could influence software delivered to privileged Kubernetes workloads.

Recommendation

Restrict production registry write access, implement image signing and verification, and enforce controlled CI/CD promotion.

Phase 93 — Positive Security Observations

Document successful controls.

Examples:

Dedicated Service Accounts
        ✓

Restricted Cluster RBAC
        ✓

Non-Root Containers
        ✓

NetworkPolicies Present
        ✓

Production Namespace Segmented
        ✓

Secrets Stored Externally
        ✓

Workload Identity Used Instead of Static Keys
        ✓

Kubernetes Audit Logging Enabled
        ✓

Phase 94 — Logging and Detection

Important telemetry may include:

Kubernetes Audit Logs

Container Runtime Logs

Application Logs

Ingress Logs

Cloud Audit Logs

Cloud IAM Logs

Network Telemetry

Falco / Runtime Security

SIEM

Phase 95 — Detection Questions

For each attack path ask:

What Action Occurs?

Which Kubernetes Event Records It?

Which Cloud Event Records It?

Which Detection Should Trigger?

Who Investigates?

What Evidence Remains?

Phase 96 — Example Detection Chain

Unexpected Deployment Modification
             ↓
Kubernetes Audit Log
             ↓
Detection Rule
             ↓
SIEM
             ↓
SOC Investigation

Another:

Unexpected Cloud Secret Access
            ↓
Cloud Audit Log
            ↓
Identity Analytics
            ↓
Alert

Phase 97 — Runtime Detection

Runtime security can help detect suspicious behaviour inside containers.

Possible enterprise controls include:

Falco

Cloud Runtime Security

EDR for Containers

Kubernetes Audit Analytics

The objective is not to evade them.

Instead ask:

Would our authorised validation have generated meaningful security telemetry?

Phase 98 — Root Cause Analysis

Your findings may reveal themes such as:

Overprivileged Kubernetes Identities

Weak Workload Isolation

Excessive Developer Permissions

Overprivileged Cloud Workload Identities

Weak Network Segmentation

Insecure Container Configuration

Poor Secret Governance

Weak Supply Chain Controls

Insufficient Detection

Phase 99 — Risk Prioritisation

Consider:

Initial Access Required

Application Exposure

Container Privilege

Kubernetes RBAC

Namespace Scope

Cloud IAM Privilege

Data Sensitivity

Network Reach

Attack Path Length

Detection Coverage

Business Impact

Phase 100 — Remediation Priorities

Immediate

Break validated critical attack paths

Reduce excessive Kubernetes RBAC

Reduce excessive cloud IAM

Restrict privileged containers

Protect exposed sensitive resources

Remove unnecessary secrets access

Short Term

Deploy NetworkPolicies

Review service accounts

Harden pod security

Improve namespace isolation

Review registry permissions

Strengthen workload identities

Strategic

Kubernetes Security Baselines

Policy as Code

Workload Identity Governance

Zero Trust Networking

Software Supply Chain Security

Centralised Kubernetes Logging

Continuous RBAC Reviews

Runtime Security Monitoring

Phase 101 — Remediation Matrix

Finding	Immediate	Strategic	Owner
K8S-001	Reduce SA permissions	RBAC governance	Platform
K8S-002	Restrict deployment control	Separation of duties	DevOps
K8S-003	Reduce cloud IAM	Workload identity governance	Cloud Security
K8S-004	Remove runtime privilege	Pod security baseline	App Team
K8S-005	Add NetworkPolicy	Zero Trust networking	Platform
K8S-006	Move sensitive config	Secret governance	Security
K8S-008	Restrict registry write	Supply-chain controls	DevSecOps

Phase 102 — Retesting

Before:

Developer
   ↓
Modify API Workload
   ↓
api-sa
   ↓
Cloud Workload Identity
   ↓
Sensitive Secret

After:

Developer
   ↓
Required Deployment Actions
   ✓

API Workload
   ↓
Dedicated api-sa
   ↓
Required Kubernetes Resources
   ✓

api-sa
   ↓
Unrelated Cloud Secret
   X

Phase 103 — Retest Network Isolation

Before:

Development Pod
      ↓
Production Service
      ✓

After:

Development Pod
      ↓
Production Service
      X

while required application paths remain:

Web
 ↓
API
 ↓
Database
 ✓

Phase 104 — Retest Status

Use:

Resolved

Partially Resolved

Not Resolved

Risk Accepted

Phase 105 — Final Architecture Diagram

Your final architecture may resemble:

                           Internet
                              │
                              ↓
                           Ingress
                              │
                              ↓
                           web-app
                              │
                           web-sa
                              │
                              ↓
                           api-app
                              │
                           api-sa
                           /    \
                          ↓      ↓
                 Kubernetes    Workload
                    RBAC       Identity
                                  │
                                  ↓
                              Cloud IAM
                                  │
                         ┌────────┴────────┐
                         ↓                 ↓
                      Storage           Secrets


Developer
   │
   └── Deployment Permission
              ↓
           api-app

This diagram should make security relationships visible immediately.

Phase 106 — Final Attack Narrative

A professional narrative might read:

The assessment began with authorised development-level access to the CloudNova Kubernetes environment. Cluster and RBAC analysis identified that the development identity could modify an application workload operating under a dedicated Kubernetes service account. That service account was mapped through workload identity to a cloud IAM principal with access to a sensitive synthetic secret. The combined relationship created a cross-layer attack path from developer access through Kubernetes workload control and workload identity into the underlying cloud environment. The path resulted from excessive workload-management permissions and overprivileged workload identity rather than a single software vulnerability.

That is much stronger than:

Kubernetes was misconfigured.

Phase 107 — Enterprise Report Structure

Create:

Kubernetes & Container Enterprise Compromise Assessment

1. Executive Summary

2. Engagement Objectives

3. Scope

4. Rules of Engagement

5. Cluster Architecture

6. Methodology

7. Namespace Inventory

8. Workload Inventory

9. Container Security Assessment

10. Kubernetes RBAC Assessment

11. Service Account Assessment

12. Secrets Security Assessment

13. Pod Security Assessment

14. Network Security Assessment

15. Workload Identity Assessment

16. Cloud IAM Integration Assessment

17. Container Supply Chain Assessment

18. Logging & Detection Assessment

19. Attack Paths

20. Validated Findings

21. Positive Security Observations

22. Root Cause Themes

23. Remediation Roadmap

24. Retest Results

25. Evidence Appendix

Phase 108 — Executive Summary Questions

Your executive summary should answer:

What Was Tested?

Could Application Compromise Expand?

Could Container Compromise Reach Kubernetes?

Could Kubernetes Privilege Reach Cloud IAM?

Were Namespace Boundaries Effective?

Were Workload Identities Least Privileged?

Were Sensitive Secrets Protected?

Could Development Access Affect Production?

Which Controls Worked?

Which Attack Paths Matter Most?

What Should Be Fixed First?

Phase 109 — Final Project Deliverables

Complete:

Project 04 - Kubernetes Enterprise Assessment/
│
├── 01 Engagement
│   ├── Scope.md
│   ├── Rules-of-Engagement.md
│   └── Objectives.md
│
├── 02 Architecture
│   ├── Initial-Architecture.md
│   └── Final-Architecture.md
│
├── 03 Cluster Discovery
│   └── Cluster-Inventory.md
│
├── 04 Namespaces
│   └── Namespace-Inventory.md
│
├── 05 Workloads
│   └── Workload-Inventory.md
│
├── 06 Containers
│   └── Container-Security-Assessment.md
│
├── 07 RBAC
│   ├── RBAC-Matrix.md
│   └── Effective-Permissions.md
│
├── 08 Service Accounts
│   └── Service-Account-Map.md
│
├── 09 Secrets
│   └── Secrets-Access-Matrix.md
│
├── 10 Pod Security
│   └── Pod-Security-Assessment.md
│
├── 11 Network Security
│   ├── NetworkPolicy-Assessment.md
│   └── Network-Flow-Matrix.md
│
├── 12 Workload Identity
│   └── Workload-Identity-Map.md
│
├── 13 Cloud IAM
│   └── Cloud-IAM-Relationship-Map.md
│
├── 14 Logging
│   └── Logging-and-Detection-Assessment.md
│
├── 15 Attack Paths
│   └── Attack-Path-Register.md
│
├── 16 Evidence
│   └── Evidence-Register.md
│
├── 17 Findings
│   └── Findings-Register.md
│
├── 18 Report
│   └── Kubernetes-Enterprise-Assessment.md
│
└── 19 Retest
    └── Retest-Report.md

Phase 110 — Student Submission Checklist

ENGAGEMENT

[ ] Scope documented
[ ] Cluster documented
[ ] Context confirmed
[ ] Authorised namespaces identified
[ ] ROE understood
[ ] Stop conditions understood

CLUSTER

[ ] Cluster architecture understood
[ ] Nodes inventoried where authorised
[ ] Namespaces inventoried
[ ] Critical namespaces identified
[ ] Kubernetes API exposure considered

WORKLOADS

[ ] Pods inventoried
[ ] Deployments inventoried
[ ] Services inventoried
[ ] Workload identities mapped
[ ] Container images documented

CONTAINER SECURITY

[ ] Runtime users reviewed
[ ] Privileged mode reviewed
[ ] Privilege escalation reviewed
[ ] Linux capabilities reviewed
[ ] Host namespaces reviewed
[ ] HostPath volumes reviewed
[ ] Read-only filesystem considered

RBAC

[ ] Roles reviewed
[ ] ClusterRoles reviewed
[ ] RoleBindings reviewed
[ ] ClusterRoleBindings reviewed
[ ] Effective permissions reviewed
[ ] Wildcard permissions investigated
[ ] Cluster-wide permissions investigated

SERVICE ACCOUNTS

[ ] Service accounts inventoried
[ ] Workloads mapped
[ ] Default SA usage reviewed
[ ] Credential automounting reviewed
[ ] RBAC permissions mapped
[ ] Cloud identity relationships mapped

SECRETS

[ ] Secret metadata reviewed
[ ] Secret access permissions reviewed
[ ] Workload requirements validated
[ ] ConfigMaps checked for sensitive data
[ ] External secret stores identified
[ ] No unnecessary secret values collected

POD SECURITY

[ ] Security contexts reviewed
[ ] Pod Security controls reviewed
[ ] Admission policies reviewed
[ ] Policy exceptions reviewed

NETWORK

[ ] NetworkPolicies inventoried
[ ] Namespace isolation reviewed
[ ] Ingress paths reviewed
[ ] Egress paths reviewed
[ ] Internal service reachability reviewed
[ ] Required network-flow matrix created

WORKLOAD IDENTITY

[ ] Kubernetes identities mapped
[ ] Cloud identities mapped
[ ] Cloud permissions reviewed
[ ] Cross-layer trust analysed
[ ] Excessive cloud access identified

SUPPLY CHAIN

[ ] Registry permissions considered
[ ] Image trust reviewed
[ ] Image update process reviewed
[ ] CI/CD deployment identities reviewed

LOGGING

[ ] Kubernetes audit logging reviewed
[ ] Runtime logging reviewed
[ ] Cloud logging reviewed
[ ] Detection opportunities identified

ATTACK PATHS

[ ] Hypothesis register created
[ ] Identity graph created
[ ] Kubernetes paths analysed
[ ] Cloud paths analysed
[ ] Cross-layer 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 completed

Phase 111 — Skills You Should Demonstrate

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

How do you begin a Kubernetes security assessment?

Why must you confirm the current Kubernetes context?

How do namespaces affect security?

What is Kubernetes RBAC?

What is the difference between Role and ClusterRole?

What is the purpose of RoleBinding and ClusterRoleBinding?

How do you determine effective Kubernetes permissions?

Why are Kubernetes service accounts important?

Why should workloads use dedicated service accounts?

Why can automatic service account credentials increase risk?

Why are privileged containers dangerous?

Why are Linux capabilities important?

Why can hostPath weaken container isolation?

How do NetworkPolicies reduce blast radius?

Why should egress be reviewed?

Why should Kubernetes Secrets not automatically be considered secure?

How does workload identity connect Kubernetes to cloud IAM?

How can workload control create indirect cloud privilege?

How can container registry permissions become an attack path?

How do you connect application, Kubernetes, and cloud risk into one attack narrative?

Phase 112 — Interview Story

You should now be able to explain:

In a CloudNova enterprise Kubernetes assessment, I started with authorised development-level access and mapped the cluster, namespaces, workloads, service accounts, RBAC, NetworkPolicies, and workload identities. I identified that the development identity could modify an application workload using a Kubernetes service account mapped to a more privileged cloud identity. The cloud identity had access to a sensitive synthetic secret that the developer could not access directly. I documented the cross-layer path from developer permissions through workload control, Kubernetes identity, workload federation, and cloud IAM. I validated only the minimum evidence necessary and recommended reducing deployment permissions, narrowing Kubernetes RBAC, restricting the cloud workload identity, and strengthening network isolation.

This demonstrates:

Container Security
        +
Kubernetes Security
        +
Kubernetes RBAC
        +
Workload Identity
        +
Cloud IAM
        +
Attack-Path Analysis
        +
Enterprise Reporting

Key Takeaways

Project 04 connects all the major security layers you have studied.

Remember:

A container compromise may become a Kubernetes compromise.

A Kubernetes compromise may become a cloud compromise.

Namespaces alone do not guarantee isolation.

Kubernetes RBAC must be analysed as an identity graph.

Service accounts are security principals.

Every important workload should have a clear identity requirement.

Workload control can create indirect privilege.

Privileged containers weaken isolation.

Host namespaces and hostPath mounts deserve careful review.

Secrets access should follow least privilege.

ConfigMaps should not contain sensitive credentials.

NetworkPolicies can reduce lateral movement opportunities.

Egress security matters as much as ingress security.

Workload identity connects Kubernetes directly to cloud IAM.

Cloud IAM privilege determines how far a Kubernetes compromise may travel.

Container registries and CI/CD pipelines are part of the Kubernetes attack surface.

A hypothesis is not a finding.

Use minimum necessary validation.

Cross-layer attack paths provide more value than isolated misconfiguration lists.

Look for remediation choke points capable of breaking several paths.

Retest the complete path after remediation.

Your enterprise Kubernetes methodology is:

Scope
  ↓
Confirm Cluster Context
  ↓
Map Cluster
  ↓
Inventory Namespaces
  ↓
Inventory Workloads
  ↓
Assess Containers
  ↓
Map Service Accounts
  ↓
Analyse Kubernetes RBAC
  ↓
Assess Secrets
  ↓
Assess Pod Security
  ↓
Assess NetworkPolicies
  ↓
Map Workload Identity
  ↓
Map Cloud IAM
  ↓
Assess Supply Chain
  ↓
Assess Logging
  ↓
Build Identity Graph
  ↓
Develop Hypotheses
  ↓
Build Cross-Layer Attack Paths
  ↓
Validate Safely
  ↓
Collect Evidence
  ↓
Analyse Business Impact
  ↓
Report
  ↓
Remediate
  ↓
Retest

What’s Next?

➡️ Project 05 — Multi-Cloud Enterprise Red Team Capstone

Project 05 will be the final project in 09 — Enterprise Cloud Pentesting Projects.

You will move beyond a single platform and assess an interconnected enterprise environment containing:

Internet
   ↓
Application
   ↓
Kubernetes
   ↓
Cloud Workload Identity
   ↓
AWS / Azure / Google Cloud
   ↓
Enterprise Identity
   ↓
Critical Data

You will bring together:

• External cloud reconnaissance

• AWS IAM

• Microsoft Entra ID

• Azure RBAC

• Google Cloud IAM

• Service accounts

• Kubernetes RBAC

• Workload identities

• Container security

• Secrets

• Cloud networking

• Cross-cloud trust

• CI/CD

• Attack-path analysis

• Security telemetry

• Evidence management

• Executive reporting

• Remediation planning

• Retesting

The final question becomes:

Can multiple individually moderate cloud weaknesses be chained across identity, workload, Kubernetes, and cloud boundaries to create a realistic enterprise compromise path?