How reverse-skill Handles Cloud and Kubernetes Security Tasks: Routing and Assessment Workflow

reverse-skill treats cloud and Kubernetes assessments as a dedicated skill triggered by routing rule R23, enforcing a four-phase workflow that verifies identity, audits cloud control planes, inspects container runtimes, and analyzes Kubernetes RBAC configurations.

The zhaoxuya520/reverse-skill repository provides an automated routing system for security assessments, treating cloud and Kubernetes environments as a specialized competency. When analysts hint at container escapes or cloud misconfigurations, the routing engine automatically selects the Cloud/K8s skill and guides them through a structured, authorization-first methodology. This approach ensures consistent evaluation of AWS, Azure, GCP, and Kubernetes attack surfaces while preventing accidental cross-tenant scanning.

Routing Engine Configuration

The routing logic resides in skills/config/routing.json, where entry R23 specifically handles cloud and Kubernetes contexts. This rule uses a must regex pattern that matches hints containing keywords like kubernetes, k8s, container-escape, docker escape, cloud security, or IMDS.

When the master routing script (skills/scripts/master-route.sh on Linux/macOS or skills/scripts/master-route.ps1 on Windows) processes a hint such as "kubernetes container escape", it scores R23 highest and automatically loads the Cloud/K8s skill as the primary task handler. The routing decision requires no manual intervention—the regex match triggers the skill selection immediately.

The Four-Phase Assessment Workflow

The Cloud/K8s skill definition in skills/cloud-k8s/SKILL.md establishes a strict four-phase methodology that analysts must follow sequentially.

Phase 1: Identity and Scope Verification

Before executing any cloud commands, analysts must complete the case-init + scope step marked as ACTION REQUIRED in the skill documentation. This phase verifies the cloud identity (AWS Access Keys, Azure credentials, GCP service accounts, or Kubernetes ServiceAccounts) and explicitly defines the authorized scope including account IDs, cluster names, and namespaces. This guardrail prevents accidental cross-tenant scanning or privilege escalation outside the engagement boundary.

Phase 2: Cloud Control Plane Enumeration

Once scope is confirmed, the skill directs analysts to run vendor-specific commands to enumerate IAM permissions and misconfigured metadata services. The workflow includes running aws sts get-caller-identity to verify the authenticated principal, followed by aws s3 ls to identify public buckets or excessive permissions. This phase targets cloud-specific misconfigurations including vulnerable IMDS endpoints and overly permissive IAM policies across AWS, Azure, and GCP environments.

Phase 3: Container Runtime Inspection

The third phase shifts focus to the container layer, inspecting runtime configurations for privileged flags, dangerous host mounts, excessive capabilities, and image vulnerabilities. The skill recommends Trivy for scanning container images and checks for container escape vectors such as writable cgroup directories or exposed Docker sockets.

Phase 4: Kubernetes Cluster Analysis

The final phase addresses the Kubernetes control plane and workload security. Analysts execute kubectl auth can-i --list to map their effective permissions, then enumerate cluster-wide resources using kubectl get pods,secrets,svc -A. The workflow includes auditing RBAC configurations, inspecting secrets for hardcoded credentials, and verifying admission controller policies. The skill references skills/cloud-k8s/references/k8s-cloud-checklist.md for comprehensive hardening verification.

Execution Flow and Safety Guards

Analysts trigger the workflow through platform-specific entry points:

# Linux/macOS invocation

bash skills/scripts/master-route.sh --hint "kubernetes container escape"

# Windows invocation

powershell -NoProfile -ExecutionPolicy Bypass -File skills/scripts/master-route.ps1 -Hint "kubernetes container escape"

When the hint matches R23's regex pattern, the routing engine automatically opens skills/cloud-k8s/SKILL.md and enforces the four-phase progression. The case-init + scope requirement acts as a hard gate; the skill documentation explicitly prevents proceeding to cloud enumeration until proper authorization is documented, minimizing the risk of unintended impact on production environments.

Extending Cloud Security Coverage

The architecture supports extending cloud capabilities without modifying core scripts. Because routing depends solely on skills/config/routing.json, adding support for new cloud providers or Kubernetes distributions requires only:

1. Adding new regex patterns to the R23 entry (or creating new routing entries)
2. Creating corresponding skill documentation in a new SKILL.md file
3. Referencing additional toolchains (such as kube-bench, audit, pacu, or nuclei) in the skill definition

The master routing scripts remain untouched during these extensions, ensuring stable platform behavior while allowing rapid adaptation to emerging cloud security scenarios.

Summary

• Routing rule R23 in skills/config/routing.json automatically triggers on cloud and Kubernetes keywords including k8s, container-escape, and IMDS
• Four-phase workflow in skills/cloud-k8s/SKILL.md enforces Identity/Scope verification, Cloud Control Plane auditing, Container inspection, and Kubernetes analysis
• Mandatory authorization step prevents accidental cross-tenant scanning through the case-init + scope requirement
• Recommended toolchain includes kubectl, Trivy, kube-bench, pacu, and nuclei for comprehensive coverage
• Extensible routing requires only JSON updates to add new cloud providers without modifying master-route.sh or master-route.ps1

Frequently Asked Questions

How does reverse-skill determine when to activate the Cloud/K8s skill?

The routing engine in skills/config/routing.json evaluates entry R23 whenever a hint contains keywords like kubernetes, k8s, docker escape, cloud security, or IMDS. The regex pattern in the must field scores these hints highest and automatically selects the Cloud/K8s skill from skills/cloud-k8s/SKILL.md without requiring manual skill selection.

What prevents unauthorized cloud resource scanning in reverse-skill?

The skill enforces an ACTION REQUIRED checkpoint before Phase 2 execution, requiring analysts to complete case-init + scope documentation. This verifies cloud identity (via aws sts get-caller-identity or equivalent) and explicitly defines the authorized account, cluster, or namespace boundaries. The workflow structure prevents proceeding to enumeration commands until this authorization step is satisfied.

Which vulnerability scanners does the Cloud/K8s skill recommend for containers?

According to skills/cloud-k8s/SKILL.md, the primary recommended tool for container image scanning is Trivy, which detects CVEs in OS packages and language dependencies. For runtime configuration auditing, the skill references kube-bench and audit tools to check for CIS benchmark violations and excessive capabilities that could enable container escapes.

How can I add support for additional cloud providers to reverse-skill?

Add new regex patterns to entry R23 in skills/config/routing.json to match provider-specific keywords (such as oracle, alibaba, or ibm cloud). Then create a new skill directory (e.g., skills/oracle-cloud/SKILL.md) documenting provider-specific commands and enumeration techniques. The existing routing scripts (master-route.sh and master-route.ps1) require no modifications, as they dynamically load any skill referenced in the routing table.

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