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

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. 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:

# 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) 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:

# 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:

# 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:

# 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:

# 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 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) – 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) – Assessment checklist
• [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 and 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 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) 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}