Kubernetes live rbac mutation guard
Skill Raishin/vanguard-frontier-agentic/skills/kubernetes/kubernetes-live-rbac-mutation-guard
Curated marketplace of AI skills, agents, and rules for cloud, zero-trust, and compliance-aware engineering - works with Claude Code, Codex, Cursor, Copilot, and more.
npx -y skills add Raishin/vanguard-frontier-agentic --skill kubernetes-live-rbac-mutation-guardAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 18 stars18 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Guard live kubectl apply, create, or delete operations on Kubernetes RBAC objects — Roles, ClusterRoles, RoleBindings, ClusterRoleBindings — with privilege-escalation verb detection, scope assessment, current-state diff, and explicit approval before any write. Use only when an intentional RBAC mutation is requested against a confirmed cluster target.
SKILL.md
3.8 KB, as published. Nobody here has run it
Kubernetes Live RBAC Mutation Guard
Purpose
Act as the guarded live Kubernetes operator for kubernetes-live-rbac-mutation-guard work. RBAC changes are additive and permanent with no built-in rollback or expiry. A mistaken ClusterRoleBinding cannot be auto-reverted. Treat every RBAC mutation as irreversible until the previous state is captured and the delete command is confirmed ready.
When to use
Use this skill when:
- a Role, ClusterRole, RoleBinding, or ClusterRoleBinding must be created, modified, or deleted in a live cluster
- a workload identity request requires binding a ServiceAccount to an existing or new role and blast radius must be confirmed before kubectl apply
- an RBAC audit finds dangerous bindings that must be removed and rollback impact on dependent workloads must be assessed
Lean operating rules
- Prefer live cluster evidence from
kubectlwhen available; fall back to official Kubernetes documentation and sanitized YAML provided by the user. - Do not execute any RBAC mutation until cluster context, namespace (if applicable), target object name, principal, and exact permission delta are all explicit.
- Capture the current state of the target object (
kubectl get ... -o yaml) as rollback evidence before any write. - Flag the following as high-severity and require explicit justification before proceeding:
- Any Role or ClusterRole granting
escalate,bind, orimpersonateverbs — privilege escalation vectors that bypass Kubernetes' own controls - Any ClusterRoleBinding to
cluster-adminfor a non-infrastructure ServiceAccount - Any wildcard verb (
*) or wildcard resource (*) in any Role or ClusterRole - Any binding to the
defaultServiceAccount in any namespace — shared blast radius - Deletion of a ClusterRoleBinding without confirming which workloads depend on it
- Any Role or ClusterRole granting
- If the request skips cluster-context confirmation, object diff, or rollback readiness, push back.
- Never print kubeconfig contents, bearer tokens, service account JWT tokens, or raw cluster credentials. Summarize sanitized evidence only.
- Load references only when needed.
References
Load these only when needed:
- Preflight commands — kubectl commands to inspect cluster context, current RBAC state, and capture rollback baseline before any mutation.
- Rollback playbook — how to undo an RBAC mutation and verify dependent workloads are not broken.
- Permission model — least-privilege patterns for common workload identity scenarios and dangerous verb/resource combinations.
- Official sources — authoritative Kubernetes documentation links.
Response minimum
Return, at minimum:
- confirmed cluster context (cluster name, namespace, active user or service account)
- current state of the target RBAC object (diff baseline)
- privilege-escalation verb and high-severity resource assessment of the proposed change
- scope assessment: namespace-scoped Role vs cluster-scoped ClusterRole necessity
- approval status with explicit justification
- rollback command (
kubectl deleteorkubectl apply -f <previous-state>) - post-mutation verification steps (
kubectl auth can-ichecks) or refusal reason