# Cloud-K8s Security Assessment Workflow: A Four-Phase Methodology

> Master the cloud-k8s security assessment workflow with our four-phase methodology. Learn authorized penetration testing for cloud, containers, and Kubernetes.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: tutorial
- Published: 2026-08-20

---

**The cloud-k8s security assessment workflow is a structured four-phase methodology for authorized penetration testing of cloud services, container runtimes, and Kubernetes clusters, defined in the `reverse-skill` repository.**

This guide walks through the complete cloud-k8s security assessment workflow as implemented in [`zhaoxuya520/reverse-skill`](https://github.com/zhaoxuya520/reverse-skill). The methodology balances thorough coverage with strict authorization boundaries, ensuring assessors can systematically identify misconfigurations while staying within legal and ethical limits.

## Phase 1: Identity & Scope

Every assessment begins with **credential verification and scope definition**. This phase establishes who you are and what you are permitted to test.

Core activities include:

- Identify the **cloud access key**, **service-account token**, or **node SSH credentials** you will use
- Define the assessment boundary (single account, single cluster, or specific namespace)
- Explicitly verify `authorized_target_only` before proceeding

Common validation commands:

```bash

# AWS identity verification

aws sts get-caller-identity

# GCP authentication status

gcloud auth list

# Azure account context

az account show

```

The workflow mandates completing this phase's **self-check** (documented in [[`skills/cloud-k8s/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/cloud-k8s/SKILL.md)](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/cloud-k8s/SKILL.md) lines 95-100) to confirm authorization boundaries are documented and understood.

## Phase 2: Cloud Control Plane Assessment

With scope confirmed, the **cloud control plane assessment** phase enumerates cloud-level resources andmisconfigurations that could enable privilege escalation or data exfiltration.

### Key Assessment Areas

- **IAM permissions** – Query policies for over-privileged roles, `PassRole` grants, and broad resource ARNs
- **Storage exposure** – Review bucket policies, encryption settings, and public access configurations
- **Metadata service attacks** – Test **IMDS (Instance Metadata Service)** exposure for **SSRF vulnerabilities**
- **Cross-account paths** – Identify role assumption chains that could pivot between environments

Typical commands for this phase:

```bash

# Enumerate IAM policies scoped to local account

aws iam list-policies --scope Local

# List S3 buckets and their permissions

aws s3 ls

# Test IMDS accessibility (classic SSRF vector)

curl -s http://169.254.169.254/latest/meta-data/iam/info

```

The **metadata SSRF** test at `169.254.169.254` is a critical control point—exposed instance metadata frequently yields temporary credentials that compromise entire cloud accounts.

## Phase 3: Container Runtime Security

The **container runtime assessment** phase examines the host and container environment for **container escape vectors** and image vulnerabilities.

### Escape Vector Analysis

Assessors evaluate:

- **Privileged containers** – Full host access enabled via `HostConfig.Privileged`
- **Dangerous volume mounts** – `hostPath`, Docker socket (`/var/run/docker.sock`), and sensitive host directories
- **Linux capabilities** – Excessive `CAP_SYS_ADMIN`, `CAP_NET_ADMIN`, or `CAP_SYS_PTRACE` grants
- **Network namespace sharing** – `hostNetwork` exposures that bypass network isolation

### Vulnerability Scanning

Image security validation uses tools like **Trivy**:

```bash

# Inspect all running containers for privileged status

docker inspect $(docker ps -q) | jq '.HostConfig.Privileged'

# Scan container image for CVEs

trivy image mycompany/webapp:latest

```

Runtime escape paths represent high-severity findings—privileged containers with hostPath mounts often allow direct host filesystem access, effectively nullifying container isolation.

## Phase 4: Kubernetes Cluster Security

The final **Kubernetes cluster assessment** phase reviews cluster-level configurations, RBAC policies, and secrets management.

### RBAC Permission Analysis

Verify identity permissions and enumerate excessive grants:

```bash

# List all permissions for current user/context

kubectl auth can-i --list

# Review cluster-wide role bindings for admin access

kubectl get clusterrolebindings

```

### Resource Enumeration Across Namespaces

Cross-namespace visibility often reveals over-permissioning:

```bash

# Enumerate pods, secrets, and services in all namespaces

kubectl get pods,secrets,svc -A

```

### High-Value Control Points

- **Exposed etcd** – Direct etcd access bypasses Kubernetes API audit logging
- **Dangerous admission webhooks** – Webhooks with weak authentication can mutate or validate arbitrary resources
- **Permissive network policies** – Missing or overly broad policies enable lateral movement

The cluster phase concludes with the same **self-check protocol** as previous phases, ensuring all findings are reproducible, documented, and within authorized scope.

## Reference Checklist and Supporting Documentation

The **[`k8s-cloud-checklist.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/k8s-cloud-checklist.md)** reference file provides a compact, phase-aligned checklist that mirrors the workflow structure. Assessors use this to track completion of each control point during live engagements.

Required documentation includes:

- [[`skills/cloud-k8s/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/cloud-k8s/SKILL.md)](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/cloud-k8s/SKILL.md) – Complete workflow definition with tool chain (kubectl, trivy, kube-bench, pacu, nuclei)
- [[`skills/cloud-k8s/references/k8s-cloud-checklist.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/cloud-k8s/references/k8s-cloud-checklist.md)](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/cloud-k8s/references/k8s-cloud-checklist.md) – Assessment checklist
- [[`skills/field-journal/precedent-pentest.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/field-journal/precedent-pentest.md)](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/field-journal/precedent-pentest.md) – Authorization record requirements

## Summary

The cloud-k8s security assessment workflow provides a systematic approach to authorized cloud and Kubernetes testing:

- **Four sequential phases** ensure comprehensive coverage without scope creep
- **Self-check gates** at each phase enforce authorization boundaries and reproducibility
- **Metadata SSRF, IAM over-permission, container escapes, and RBAC hygiene** represent the core vulnerability classes targeted
- **Reference documentation** in [`SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/SKILL.md) and [`k8s-cloud-checklist.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/k8s-cloud-checklist.md) supports consistent execution across assessors

## Frequently Asked Questions

### What authorization is required before starting a cloud-k8s assessment?

Assessors must complete the identity verification in Phase 1 and review the [`precedent-pentest.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/precedent-pentest.md) authorization record. The `authorized_target_only` verification is mandatory—testing without explicit documented permission violates the workflow's ethical framework and legal requirements.

### How does the workflow prevent destructive actions?

Each phase ends with a self-check (lines 95-100 in [`SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/SKILL.md)) that validates findings against the documented scope. The methodology emphasizes **read-only enumeration**—commands like `kubectl get` and `aws s3 ls` rather than write operations—ensuring assessment activities cannot damage target environments.

### What tools does the cloud-k8s workflow recommend?

The tool chain includes **kubectl** for K8s interaction, **trivy** for image scanning, **kube-bench** for CIS benchmark validation, **pacu** for AWS exploitation, and **nuclei** for automated vulnerability detection. Specific tool selection depends on the target environment's cloud provider and technology stack.

### Can this workflow assess multi-cloud environments?

Yes—the methodology is cloud-agnostic at the framework level. Phase 2 commands adapt to AWS (`aws`), GCP (`gcloud`), or Azure (`az`) APIs, while Phases 3-4 target container and Kubernetes constructs that operate consistently across providers. Assessors substitute provider-specific tooling while maintaining the same assessment logic.