@raishin/vanguard-frontier-agentic 1.2.0 → 1.3.0

package/skills/kubernetes/external-secrets-operator-review/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "external-secrets-operator-review",
+  "name": "External Secrets Operator Review",
+  "type": "skill",
+  "provider": "kubernetes",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review ESO SecretStore, ClusterSecretStore, ExternalSecret, and PushSecret for scope creep, auth anti-patterns, refresh interval risks, and dataFrom blast radius.",
+  "source_type": "original",
+  "official_docs": [
+    "https://external-secrets.io/latest/introduction/overview/",
+    "https://external-secrets.io/latest/api/secretstore/",
+    "https://external-secrets.io/latest/api/externalsecret/",
+    "https://external-secrets.io/latest/api/clustersecretstore/",
+    "https://external-secrets.io/latest/provider/aws-secrets-manager/",
+    "https://external-secrets.io/latest/provider/azure-key-vault/"
+  ],
+  "security_notes": "ClusterSecretStore with no namespace selector grants every namespace access to every external secret reachable by the store credentials. Static credentials in SecretStore auth create a credential-to-access-credentials chain where compromise of the K8s Secret gives full access to the external store.",
+  "last_verified": "2026-05-02",
+  "path": "skills/kubernetes/external-secrets-operator-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/kubernetes/external-secrets-operator-review/references/workflow-and-output.md

@@ -0,0 +1,280 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide one or more of the following as sanitized YAML snippets (no real ARNs with account IDs, no actual secret values, no real tenant IDs or vault addresses that identify their environment):
+- `SecretStore` or `ClusterSecretStore` manifest(s)
+- `ExternalSecret` manifest(s)
+- `PushSecret` manifest(s), if any
+- Optional: ESO operator deployment manifest (to check version and RBAC permissions)
+- Optional: description of the external store provider (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault, 1Password Connect) and the auth method in use
+
+If the user provides only a partial set, note which resources are absent and scope findings accordingly.
+
+### Step 2 — SecretStore vs ClusterSecretStore scope audit
+
+For every `ClusterSecretStore` resource:
+- Check whether `spec.conditions[].namespaceSelector` or `spec.conditions[].namespaces` is set
+- If absent: flag as HIGH — every namespace can reference this store
+
+```yaml
+# HIGH — no namespace selector; any ExternalSecret in any namespace can use this store
+apiVersion: external-secrets.io/v1beta1
+kind: ClusterSecretStore
+metadata:
+  name: aws-global
+spec:
+  provider:
+    aws:
+      service: SecretsManager
+      region: us-east-1
+      auth:
+        jwt:
+          serviceAccountRef:
+            name: eso-sa
+            namespace: external-secrets
+
+# CORRECT — restrict to specific namespaces
+apiVersion: external-secrets.io/v1beta1
+kind: ClusterSecretStore
+metadata:
+  name: aws-payments
+spec:
+  conditions:
+    - namespaces:
+        - payments
+        - payments-staging
+  provider:
+    aws:
+      service: SecretsManager
+      region: us-east-1
+      auth:
+        jwt:
+          serviceAccountRef:
+            name: eso-payments-sa
+            namespace: external-secrets
+```
+
+For `SecretStore` resources: verify the namespace matches the namespace of the ExternalSecrets that reference it. A SecretStore in namespace A cannot be referenced by an ExternalSecret in namespace B.
+
+### Step 3 — Authentication method audit
+
+For every store, identify the auth method:
+
+| Auth method | Risk level | Notes |
+|-------------|-----------|-------|
+| IRSA (AWS) | Low | Preferred for EKS |
+| Azure Workload Identity | Low | Preferred for AKS |
+| GCP Workload Identity | Low | Preferred for GKE |
+| Vault Kubernetes auth | Low | Preferred for Vault |
+| Static credentials via `secretRef` | HIGH | Credential-in-credential anti-pattern |
+| Static credentials inline in manifest | CRITICAL | Never acceptable |
+
+**Static credentials pattern to flag:**
+```yaml
+# HIGH — K8s Secret holds AWS access key for the external store
+spec:
+  provider:
+    aws:
+      service: SecretsManager
+      auth:
+        secretRef:
+          accessKeyIDSecretRef:
+            name: aws-creds
+            key: access-key-id
+          secretAccessKeySecretRef:
+            name: aws-creds
+            key: secret-access-key
+```
+
+The K8s Secret `aws-creds` is itself a credential. Anyone who can read that Secret (namespace admin, over-privileged pod) gains full access to the AWS Secrets Manager path the store covers.
+
+**Correct IRSA pattern:**
+```yaml
+# CORRECT — pod identity; no static credentials
+spec:
+  provider:
+    aws:
+      service: SecretsManager
+      region: us-east-1
+      auth:
+        jwt:
+          serviceAccountRef:
+            name: eso-payments-sa
+            namespace: external-secrets
+```
+
+### Step 4 — dataFrom scope audit
+
+Review every `ExternalSecret.spec.dataFrom` stanza:
+
+**4a. `dataFrom.extract`**
+Fetches all key-value pairs from a specific secret path. Review that the path is as narrow as possible.
+```yaml
+# ACCEPTABLE — extracts all keys from a single named secret
+dataFrom:
+  - extract:
+      key: my-app/production/database
+```
+
+**4b. `dataFrom.find`**
+Fetches multiple secrets matching a regex or tag filter. HIGH blast-radius risk.
+```yaml
+# HIGH — fetches ALL secrets in the store matching any name
+dataFrom:
+  - find:
+      name:
+        regexp: ".*"
+
+# HIGH — fetches every secret under the /production/ path prefix
+dataFrom:
+  - find:
+      path: /production/
+
+# ACCEPTABLE — narrow regex scoped to a single application prefix
+dataFrom:
+  - find:
+      name:
+        regexp: "^my-app/production/[a-z-]+$"
+      tags:
+        app: my-app
+```
+
+Flag any `find` with a broad regex (`.*`, `^/`, or no regex at all) as HIGH — all matching secrets are merged into a single K8s Secret, and any pod that mounts it gets access to all of them.
+
+### Step 5 — Refresh interval compliance audit
+
+For every `ExternalSecret`, check `spec.refreshInterval`.
+
+Default is `1h`. Review against the rotation policy of the external credential:
+
+| Credential type | Typical rotation window | Recommended refreshInterval |
+|----------------|------------------------|------------------------------|
+| Database password (RDS IAM auth) | 15 minutes | `5m` or `10m` |
+| API key with 24h rotation | 24 hours | `1h` |
+| Long-lived service account key | 90 days | `1h` (acceptable) |
+| TLS certificate (Let's Encrypt) | 90 days | `12h` |
+
+```yaml
+# MEDIUM — 48h refresh on a DB password that rotates every 15 minutes
+spec:
+  refreshInterval: 48h
+  secretStoreRef:
+    name: aws-store
+    kind: ClusterSecretStore
+  target:
+    name: db-password
+  data:
+    - secretKey: password
+      remoteRef:
+        key: my-app/production/db
+        property: password
+```
+
+Flag `refreshInterval: 0` as a separate risk — it disables automatic refresh; secrets only update on ExternalSecret resource changes.
+
+### Step 6 — Target creation policy and template audit
+
+**6a. creationPolicy**
+```yaml
+# MEDIUM — Owner means ESO owns the Secret lifecycle
+target:
+  name: my-app-secret
+  creationPolicy: Owner
+```
+If the ExternalSecret is deleted (by a botched `helm uninstall`, namespace teardown, or GitOps drift), the managed K8s Secret is deleted immediately. Workloads using it crash. Recommend documenting this in runbooks and implementing deletion protection on critical ExternalSecrets.
+
+Alternative `creationPolicy: Merge` — ESO writes keys into an existing Secret but does not own its lifecycle. Review that the existing Secret exists and has the correct structure.
+
+**6b. Template correctness**
+```yaml
+# RISKY — template that silently omits a key if the remote key name changes
+target:
+  template:
+    data:
+      DB_PASS: "{{ .db_pass }}"
+      DB_HOST: "{{ .db_host }}"
+      # If the remote secret loses a key, the template renders as empty string, not an error
+```
+
+Recommend including `engineVersion: v2` and verifying that all template references have a corresponding remote key. Flag templates with no explicit key mapping verification as LOW (template drift risk).
+
+### Step 7 — PushSecret audit
+
+If `PushSecret` resources are present:
+
+**7a. Auth scope**
+PushSecret writes K8s Secret values into the external store. The auth principal for PushSecret needs write permission to the external store path. Review that:
+- The IAM role / service principal / Vault policy grants write only to the specific path, not `secretsmanager:PutSecretValue` on `*`
+- The auth principal is separate from the read-path principal (PushSecret auth should not be reused for ExternalSecret auth)
+
+**7b. Selector scope**
+```yaml
+# HIGH — pushes ALL secrets from the namespace into the external store
+spec:
+  selector:
+    secret:
+      name: ""  # empty = all secrets
+```
+
+Flag any PushSecret with an empty or wildcard selector as HIGH — it exfiltrates all K8s Secrets from the namespace into the external store.
+
+### Step 8 — ESO operator RBAC audit (if manifest provided)
+
+Review the ClusterRole bound to the ESO operator ServiceAccount:
+- ESO needs `get`, `list`, `watch` on Secrets (to read SecretStore auth credentials)
+- ESO needs `create`, `update`, `patch`, `delete` on Secrets (to manage target Secrets)
+- ESO does NOT need `get` on all Secrets cluster-wide unless ClusterSecretStore is used
+- Flag `resources: ["secrets"]` with no `resourceNames` restriction on a ClusterRole as MEDIUM
+
+### Step 9 — Produce the output
+
+Format findings using the Output section below.
+
+---
+
+## Output
+
+Return findings in this structure:
+
+```
+## Verdict
+<one sentence summary: pass / needs work / critical issues found>
+
+## Evidence level
+<live evidence | user-provided sanitized config | documentation-based | inference>
+
+## Findings
+
+### CRITICAL
+- [C1] <finding title>: <description> — <remediation>
+
+### HIGH
+- [H1] <finding title>: <description> — <remediation>
+
+### MEDIUM
+- [M1] <finding title>: <description> — <remediation>
+
+### LOW
+- [L1] <finding title>: <description> — <remediation>
+
+## Safe next actions
+1. <action>
+2. <action>
+...
+
+## Open questions
+- <question requiring user clarification>
+```
+
+---
+
+## Security notes
+
+- Never recommend using static credentials (`secretRef` pointing to a K8s Secret holding cloud credentials) as a permanent solution — always direct toward workload identity (IRSA, Azure Workload Identity, GCP Workload Identity, Vault Kubernetes auth).
+- Treat any `ClusterSecretStore` with no `namespaceSelector` as a cross-namespace trust boundary violation — flag it regardless of whether the user considers it intentional.
+- Do not recommend setting `refreshInterval: 0` on any ExternalSecret for a credential that participates in a rotation policy — zero disables automatic refresh.
+- Flag the absence of monitoring on ExternalSecret sync status (`externalsecret_sync_calls_total`, `externalsecret_status_condition`) — a failing sync that goes unalerted means the cluster silently uses a stale or deleted credential.
+- Treat `dataFrom.find` with a broad regex as equivalent to "grant this pod access to every secret in your vault that matches the regex" — make the blast radius explicit in the finding description.

package/skills/kubernetes/kubecost-chargeback-allocation-review/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: kubecost-chargeback-allocation-review
+description: Use this skill when reviewing a Kubecost or OpenCost installation for enterprise chargeback readiness. Trigger when the user asks whether cost allocation is accurate, whether label taxonomy is complete enough for chargeback, whether idle cost is properly attributed, whether the cost API is secured, or whether savings recommendations are being actioned.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# Kubecost Chargeback and Allocation Review
+
+## Purpose
+
+Review a Kubecost (or OpenCost) deployment for cost allocation accuracy, label taxonomy completeness, shared cost model selection, idle cost attribution policy, budget alert coverage, cost API authentication posture, and savings recommendation hygiene. Enterprise chargeback requires that every dollar spent can be attributed to a team, cost center, or product — gaps in label coverage, authentication, or idle allocation produce inaccurate charge-backs and hide engineering waste.
+
+## Lean operating rules
+
+- Prefer user-provided Kubecost allocation API output, Helm values, and `kubectl` label query results as primary evidence; official Kubecost and OpenCost docs are the authoritative fallback.
+- Treat the Kubecost cost allocation API or frontend exposed without SSO/ingress authentication as a HIGH finding — any pod in the cluster can enumerate other teams' spend.
+- Treat more than 20% of pod costs appearing in the "uncategorized" or "__unallocated__" bucket as a HIGH finding — chargeback to business units is impossible for that spend.
+- Treat idle cost absorbed centrally (not attributed to namespace owners) as a MEDIUM finding — it hides waste from the engineering teams responsible for right-sizing.
+- Treat PV (persistent volume) costs excluded from allocation as a MEDIUM finding — stateful teams face an invisible blind spot in their bill.
+- Treat no budget alerts configured for any namespace or team as a MEDIUM finding — teams have no cost signal until the end-of-month invoice.
+- Treat HIGH-priority savings recommendations unactioned for more than 30 days as a HIGH finding — direct, measurable cash waste with a documented fix path.
+- Distinguish OpenCost (no multi-cluster single-pane, no team RBAC) from Kubecost Enterprise (multi-cluster, RBAC, advanced savings) when scope matters for the use case.
+
+## References
+
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md)
+
+## Response minimum
+
+- Scoped target (cluster name, Kubecost version, OpenCost vs Kubecost) and evidence level
+- Cost allocation accuracy verdict (all cost components enabled or missing)
+- Label taxonomy completeness (% uncategorized, missing labels)
+- Shared cost model and idle cost attribution policy
+- Budget alert coverage (configured / absent / threshold)
+- Cost API authentication posture
+- Top savings recommendations status
+- Safe next actions and open questions

package/skills/kubernetes/kubecost-chargeback-allocation-review/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "kubecost-chargeback-allocation-review",
+  "name": "Kubecost Chargeback and Allocation Review",
+  "type": "skill",
+  "provider": "kubernetes",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review Kubecost and OpenCost cost allocation accuracy, label taxonomy completeness, shared cost model, idle cost attribution, budget alert coverage, API authentication, and savings recommendation hygiene for enterprise chargeback.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.kubecost.com/kubernetes-cost-optimization/",
+    "https://docs.kubecost.com/using-kubecost/navigating-the-kubecost-ui/cost-allocation",
+    "https://www.opencost.io/docs/",
+    "https://docs.kubecost.com/install-and-configure/advanced-configuration/cost-model",
+    "https://docs.kubecost.com/using-kubecost/navigating-the-kubecost-ui/savings",
+    "https://docs.kubecost.com/apis/apis-overview"
+  ],
+  "security_notes": "Kubecost cost allocation API without authentication exposes team-level spend data to any pod in the cluster. Multi-cluster Kubecost aggregation requires cross-cluster network access — review whether the aggregation network path is private or exposed.",
+  "last_verified": "2026-05-02",
+  "path": "skills/kubernetes/kubecost-chargeback-allocation-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/kubernetes/kubecost-chargeback-allocation-review/references/workflow-and-output.md

@@ -0,0 +1,215 @@
+# Workflow and output contract
+
+Use this reference only when performing a full Kubecost or OpenCost chargeback readiness review, producing FinOps implementation guidance, triaging a cost allocation discrepancy, or completing a cost governance production-readiness pass.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Kubecost vs OpenCost distinction and version
+- Cost allocation accuracy: all cost components enabled (compute, storage, network)
+- Label taxonomy completeness: uncategorized cost percentage, missing label coverage
+- Shared cost model: even split, proportional, or weighted — and whether it matches the chargeback agreement
+- Idle cost attribution: absorbed centrally or allocated to namespace owners
+- Budget alert configuration: thresholds, routing, and coverage
+- Cost API and frontend authentication posture
+- Savings recommendations status: HIGH-priority items and days unactioned
+
+## Safe workflow
+
+1. **Frame scope**
+   - Cluster name and cloud provider:
+   - Kubecost version (`helm list -n kubecost` or `kubectl get deployment -n kubecost -o json | jq '.items[].spec.template.spec.containers[].image'`):
+   - OpenCost or Kubecost (free tier / Business / Enterprise):
+   - Number of clusters in scope:
+   - Required outcome of this review:
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer Kubecost allocation API output, Helm values, and `kubectl` label query results as primary evidence.
+   - Supplement with Kubecost UI screenshots and savings recommendations export if available.
+   - Label each finding as `live evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Verify all cost components are captured**
+   Query the allocation API to confirm compute, storage, and network are all present:
+   ```bash
+   # Allocation API — last 7 days by namespace
+   curl "http://localhost:9090/model/allocation?window=7d&aggregate=namespace&includeIdle=true"
+
+   # Check whether network costs are enabled in Helm values
+   helm get values kubecost -n kubecost | grep -A5 'networkCosts'
+
+   # Check whether PV costs are included
+   helm get values kubecost -n kubecost | grep -A5 'persistentVolumes'
+   ```
+   If `networkCosts.enabled: false` or PV costs are missing from the allocation response,
+   flag as MEDIUM — stateful or egress-heavy teams face invisible costs.
+
+4. **Assess label taxonomy completeness**
+   Run a label audit to quantify unlabeled pods:
+   ```bash
+   # Count pods missing the cost-center label
+   kubectl get pods -A --show-labels | grep -v 'cost-center=' | grep -v 'NAME' | wc -l
+
+   # Count pods missing the team label
+   kubectl get pods -A --show-labels | grep -v 'app.kubernetes.io/team=' | grep -v 'NAME' | wc -l
+
+   # Query Kubecost for uncategorized spend share
+   curl "http://localhost:9090/model/allocation?window=7d&aggregate=label:cost-center" | \
+     jq '.data[0]["__unallocated__"].totalCost / (.data[0] | to_entries | map(.value.totalCost) | add)'
+   ```
+   If the `__unallocated__` or `__idle__` bucket represents more than 20% of total cost,
+   label taxonomy is insufficient for chargeback — flag as HIGH.
+
+5. **Check shared cost model configuration**
+   Kubecost shared cost models in `values.yaml`:
+   ```yaml
+   # Option 1: even split (each tenant pays equal share of shared infra)
+   kubecostModel:
+     sharedCostConfiguration:
+       shareIdle: false
+       sharedNamespaces: "monitoring,ingress-nginx,cert-manager"
+       shareByLabel: ""
+       shareType: "even"   # even | weighted | proportional
+
+   # Option 2: proportional (tenant pays proportional to their usage)
+   shareType: "proportional"
+
+   # Option 3: weighted (explicit percentage per tenant)
+   shareType: "weighted"
+   ```
+   If the shared cost model does not match the documented business chargeback agreement, flag as MEDIUM.
+   If no shared namespace is configured, monitoring and ingress costs are silently excluded from bills.
+
+6. **Verify idle cost attribution**
+   ```bash
+   # Check idle allocation setting
+   helm get values kubecost -n kubecost | grep -A3 'idle'
+
+   # Idle cost API
+   curl "http://localhost:9090/model/allocation?window=7d&aggregate=namespace&includeIdle=true" | \
+     jq '.data[0].__idle__'
+   ```
+   If `shareIdle: false` and the `__idle__` bucket is large (>15% of total), idle waste is hidden
+   from engineering teams. Allocating idle to namespaces creates incentive to right-size.
+   Flag as MEDIUM if idle cost is absorbed centrally without a documented policy decision.
+
+7. **Audit budget alert configuration**
+   ```bash
+   # Check for configured budget alerts via Kubecost API
+   curl "http://localhost:9090/model/budget"
+
+   # Check Kubecost alert configuration in values
+   helm get values kubecost -n kubecost | grep -A20 'alerts'
+   ```
+   A well-configured alert:
+   ```yaml
+   alerts:
+     - type: budget
+       threshold: 80       # alert at 80% — not 100%
+       window: monthly
+       aggregation: namespace
+       filter: "namespace=team-a"
+       slackWebhookUrl: https://hooks.slack.com/services/...
+   ```
+   No budget alerts configured for any namespace is a MEDIUM finding.
+   Alert threshold at 100% (no early warning) is a MEDIUM finding.
+   Alert routing to a central ops black hole (not the owning team) is a MEDIUM finding.
+
+8. **Check cost API and frontend authentication**
+   ```bash
+   # Test whether the cost API is publicly accessible without credentials
+   curl -o /dev/null -s -w "%{http_code}" http://<kubecost-service>:9090/model/allocation?window=1d
+
+   # Check ingress auth annotation
+   kubectl get ingress -n kubecost -o yaml | grep -A5 'annotations'
+   ```
+   Expected annotations for SSO-gated ingress:
+   ```yaml
+   annotations:
+     nginx.ingress.kubernetes.io/auth-url: "https://oauth2-proxy/oauth2/auth"
+     nginx.ingress.kubernetes.io/auth-signin: "https://oauth2-proxy/oauth2/start"
+   ```
+   A 200 response from the allocation API without auth headers means any cluster pod can enumerate
+   other teams' spend data — flag as HIGH.
+
+9. **Savings recommendations review**
+   ```bash
+   # Get rightsizing recommendations
+   curl "http://localhost:9090/model/savings/requestSizingV2"
+
+   # Get abandoned workload recommendations
+   curl "http://localhost:9090/model/savings/abandonedWorkloads"
+
+   # Get orphaned PV recommendations
+   curl "http://localhost:9090/model/savings/orphanedResources"
+   ```
+   Review the top 10 recommendations by estimated monthly savings. For each HIGH-priority item,
+   confirm whether it has been reviewed. Items unactioned for more than 30 days represent
+   measurable cash waste with a documented fix path — flag as HIGH.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Kubecost Chargeback and Allocation Review: <cluster-name>
+
+## Executive verdict
+- Status: CHARGEBACK READY / PARTIALLY READY / NOT READY / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+
+## Scope and assumptions
+- Cluster name and cloud provider:
+- Kubecost version and tier:
+- Review window:
+- Confirmed:
+- Unknown:
+- Out of scope:
+
+## Findings
+
+| Severity | Area | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|---|
+
+## Cost component coverage
+
+| Component | Enabled | Notes |
+|---|---|---|
+| Compute (CPU/RAM) | | |
+| Persistent volume storage | | |
+| Network egress (cross-AZ) | | |
+| Network egress (cross-region) | | |
+| GPU | | |
+
+## Label taxonomy summary
+- Total pod count:
+- Pods missing `cost-center` label:
+- Estimated uncategorized cost %:
+
+## Shared cost and idle model
+- Shared namespaces:
+- Share type:
+- Idle allocation policy:
+
+## Budget alert coverage
+- Namespaces with budget alerts:
+- Earliest warning threshold:
+- Alert routing:
+
+## Top savings opportunities
+
+| Recommendation | Est. monthly savings | Days open | Action |
+|---|---|---|---|
+
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+
+## Validation
+- Commands or checks:
+- Expected result:
+
+## Residual risk
+- <risk or explicit none>
+```

package/skills/kubernetes/kubernetes-live-rbac-mutation-guard/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: kubernetes-live-rbac-mutation-guard
+description: 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.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# 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

package/skills/kubernetes/kubernetes-live-rbac-mutation-guard/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "kubernetes-live-rbac-mutation-guard",
+  "name": "Kubernetes Live RBAC Mutation Guard",
+  "type": "skill",
+  "provider": "kubernetes",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Guard live kubectl apply/create/delete operations on Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings with privilege-escalation verb detection, scope assessment, current-state diff, and explicit approval before write.",
+  "source_type": "original",
+  "official_docs": [
+    "https://kubernetes.io/docs/reference/access-authn-authz/rbac/",
+    "https://kubernetes.io/docs/concepts/security/rbac-good-practices/",
+    "https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/",
+    "https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/"
+  ],
+  "security_notes": "Capture current RBAC object state before every mutation — there is no built-in rollback. Block escalate, bind, and impersonate verbs without explicit platform-team approval. Never approve wildcard verb or resource grants. Deleting a ClusterRoleBinding does not immediately revoke cached service account tokens.",
+  "last_verified": "2026-05-01",
+  "path": "skills/kubernetes/kubernetes-live-rbac-mutation-guard",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}