What problem does it solve? Security teams need a disciplined, evidence-gated way to confirm whether their own Kubernetes clusters expose APIs, metadata, or workloads to anonymous or low-privilege identities, without risking secrets access, privilege escalation, or production side effects. ## Core Features & Use Cases - Engagement Gating: Enforces documented authorization, locked scope, and host/identity baselines before any probe runs, treating WAF blocks, timeouts, and anomalies as inconclusive. - Read-Only Validation Workflow: Guides a fixed cadence of baseline, single-variable probe, post-baseline, oracle, and evidence collection using official API discovery and audit logs. - Strict Oracle and Stop Rules: Confirms findings only when anonymous or low-privilege reads of protected canary metadata are proven by audit/RBAC evidence, and halts immediately on secrets, token access, exec, or cross-namespace conditions. - Use Case: A red team operator verifying a self-owned cluster follows the route to compare anonymous versus approved low-privilege reads of a canary namespace, then routes CVE indicators to triage and cloud ownership questions to a cloud misconfiguration skill. ## Quick Start Use the hunt-kubernetes-exposure skill to plan an evidence-gated, read-only validation of my authorized Kubernetes cluster's public exposure and RBAC posture.
