competition-k8s-control-plane

Analyzes Kubernetes RBAC, service accounts, and controller mutations in CTF sandbox clusters.

7|4|Updated Jun 22, 2026
One-click install
npx skills add https://github.com/dbx0/skills --skill competition-k8s-control-plane-dbx0
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: competition-k8s-control-plane
Source: https://github.com/dbx0/skills/tree/main/skills/cloud-container/privilege-escalation/competition-k8s-control-plane
Command: npx skills add https://github.com/dbx0/skills --skill competition-k8s-control-plane-dbx0

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? In Kubernetes-based CTF challenges, the decisive path often runs through control-plane state rather than a single container, and it is hard to connect API permissions, admission mutations, and controller behavior to the actual workload or secret effect. This Skill provides a structured methodology for tracing principals, RBAC edges, and object mutations down to the smallest cluster action that produces the decisive result. ## Core Features & Use Cases - API Trust Path Mapping: Records namespaces, service accounts, Roles, ClusterRoles, bindings, admission hooks, and controllers, distinguishing read, create, patch, exec, and secret access. - Mutation-to-Workload Tracing: Shows how an API action becomes a pod, volume mount, secret exposure, env injection, or controller-created artifact, comparing checked-in YAML against live objects after admission and reconciliation. - Decisive Path Reduction: Compresses findings into the smallest chain of principal, API permission, mutated object, and resulting workload or secret effect, with evidence blocks kept per namespace and controller. - Use Case: During a CTF, you find a service-account token in a pod. Use this Skill to enumerate its RoleBindings, prove which API actions it allows, and demonstrate the exact object creation that exposes the flag-bearing secret. ## Quick Start Ask the assistant to map this service account's RBAC permissions and trace which cluster objects it can mutate to reach the target secret.

Frequently Asked Questions about competition-k8s-control-plane

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enumerate Kubernetes RBAC permissions for a service account?

List the Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings referencing the service account, then map each binding to its allowed verbs and resources. This Skill structures that as a principal-to-verb-to-resource chain tied to the namespace.

How to trace which controller created a pod in Kubernetes?

Inspect the pod's owner references to identify the controlling object such as a Job, ReplicaSet, or operator CRD. Then compare the live object against checked-in manifests to account for admission mutation and controller reconciliation drift.

When should I use control-plane analysis instead of container runtime analysis?

Use control-plane analysis when the decisive path involves API permissions, RBAC edges, admission webhooks, or controller behavior rather than a single container's mounts or runtime deviation. If the problem narrows to one container, switch to a container-runtime skill.

Why does live Kubernetes state differ from the checked-in YAML manifests?

Live objects differ due to API defaulting, mutating admission webhooks, and controller reconciliation after object creation. Always compare static manifests against live describes and attribute each difference to a specific admission or controller step.

What evidence should I keep when proving an RBAC escalation path?

Keep the principal side (service account, token source, namespace, binding, verb, resource), the mutation side (object manifest, admission change, controller output, owner refs), and the effect side (mounted secret, spawned pod, or recovered artifact) together in one chain.