Receber por email
← Voltar para o catálogo

kubernetes-live-rbac-mutation-guard

Protege operações kubectl apply, create ou delete em objetos RBAC do Kubernetes — Roles, ClusterRoles, RoleBindings, ClusterRoleBindings — com detecção de verbos de escalonamento de privilégios, avaliação de escopo, diff do estado atual e aprovação explícita antes de qualquer escrita. Use apenas quando uma mutação RBAC intencional for solicitada contra um alvo de cluster confirmado.

19estrelas
Atualizado há 4 meses

Ver no GitHub ↗ Licença: Apache-2.0

Como adicionar

/plugin marketplace add Raishin/vanguard-frontier-agentic

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/kubernetes-live-rbac-mutation-guard/svg)](https://www.skillteca.com.br/skills/kubernetes-live-rbac-mutation-guard)
#ai

Skills relacionadas

Ver todas de DevOps e Infra →

Alerta por categoria

Receba novas skills de DevOps e Infra toda segunda

1 email curto, só com as skills novas de DevOps e Infra. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

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 kubectl when 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, or impersonate verbs — privilege escalation vectors that bypass Kubernetes' own controls
  • Any ClusterRoleBinding to cluster-admin for a non-infrastructure ServiceAccount
  • Any wildcard verb () or wildcard resource () in any Role or ClusterRole
  • Any binding to the default ServiceAccount in any namespace — shared blast radius
  • Deletion of a ClusterRoleBinding without confirming which workloads depend on it
  • 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](references/preflight-commands.md) — kubectl commands to inspect cluster context, current RBAC state, and capture rollback baseline before any mutation.
  • [Rollback playbook](references/rollback-playbook.md) — how to undo an RBAC mutation and verify dependent workloads are not broken.
  • [Permission model](references/permission-model.md) — least-privilege patterns for common workload identity scenarios and dangerous verb/resource combinations.
  • [Official sources](references/official-sources.md) — 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 delete or kubectl apply -f <previous-state>)
  • post-mutation verification steps (kubectl auth can-i checks) or refusal reason
Compartilhar X LinkedIn