@raishin/vanguard-frontier-agentic 1.2.0 → 1.3.0

package/skills/kubernetes/kubernetes-pod-security-admission-review/metadata.json

@@ -0,0 +1,28 @@
+{
+  "id": "kubernetes-pod-security-admission-review",
+  "name": "Kubernetes Pod Security Admission Review",
+  "type": "skill",
+  "provider": "kubernetes",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Kubernetes Pod Security Admission posture across namespace labels, the three profiles (privileged, baseline, restricted), enforce/audit/warn modes, version pinning, exemptions, and the migration from deprecated PodSecurityPolicy.",
+  "source_type": "original",
+  "official_docs": [
+    "https://kubernetes.io/docs/concepts/security/pod-security-admission/",
+    "https://kubernetes.io/docs/concepts/security/pod-security-standards/",
+    "https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/",
+    "https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/",
+    "https://kubernetes.io/docs/concepts/security/security-checklist/"
+  ],
+  "security_notes": "A production namespace with no PSA label inherits cluster default which is privileged unless overridden. enforce-version latest changes semantics on every Kubernetes minor upgrade. audit and warn without enforce only log violations. PSP migration via kubectl-psp-to-psa shifts enforcement boundary; verify before disabling PSP webhooks.",
+  "last_verified": "2026-05-01",
+  "path": "skills/kubernetes/kubernetes-pod-security-admission-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/kubernetes/kubernetes-pod-security-admission-review/references/mcp-and-evidence.md

@@ -0,0 +1,49 @@
+# Evidence Path and Tooling
+
+## Evidence path
+
+1. Prefer live cluster evidence (`kubectl get namespaces --show-labels`, `kubectl get pods -n <ns> -o yaml`, and the cluster's `AdmissionConfiguration` if accessible).
+2. Fall back to the official Kubernetes documentation: Pod Security Admission, Pod Security Standards, and namespace-label enforcement guide.
+3. Ask only for sanitized namespace YAML, sanitized pod spec excerpts (focus on `securityContext`, `volumes`, `hostNetwork`, `hostPID`, `hostIPC`), and the cluster's PSA admission configuration when current-state proof matters.
+4. Label conclusions as `live evidence`, `documentation-based`, `sanitized user evidence`, or `inference`.
+
+## Useful live-evidence commands
+
+```shell
+# View PSA labels on every namespace
+kubectl get namespaces --show-labels | grep -E 'pod-security|^NAME'
+
+# Detailed namespace labels and annotations
+kubectl get namespace <ns> -o yaml | grep -A20 metadata
+
+# Check whether running pods would still admit at a stricter profile
+# (use kubectl-pod-security plugin or apply dry-run with the new label)
+kubectl label namespace <ns> pod-security.kubernetes.io/warn=restricted --overwrite --dry-run=server
+
+# Audit-mode violations end up in the audit log (cluster-admin access required)
+# Look for pod-security violations in apiserver audit log
+
+# Cluster default PSA configuration (if user has access to control plane)
+kubectl -n kube-system get pod -l component=kube-apiserver -o yaml | grep -A20 admission
+
+# Pod security context inspection
+kubectl get pod -n <ns> <pod> -o jsonpath='{.spec.securityContext}'
+kubectl get pod -n <ns> <pod> -o jsonpath='{.spec.containers[*].securityContext}'
+
+# List pods that would fail restricted profile
+kubectl get pods -A -o jsonpath='{range .items[?(@.spec.containers[*].securityContext.privileged==true)]}{.metadata.namespace}/{.metadata.name}{"\n"}{end}'
+```
+
+## Cluster state to confirm before review
+
+- **Kubernetes version** (`kubectl version`) — PSA stable in 1.25; profile semantics evolve; pin `enforce-version` to a specific minor.
+- **Cluster default profile** (cluster's `AdmissionConfiguration`) — when a namespace has no label, this is what applies.
+- **Cluster exemptions** — the `AdmissionConfiguration` can exempt usernames, runtime classes, and namespaces by name (different from per-namespace label override).
+- **Whether PSP (PodSecurityPolicy) admission is still active** — PSP was removed in 1.25 but some clusters run a PSP-equivalent webhook. Migration tools include `kubectl-psp-to-psa`.
+- **Whether other admission policies (Kyverno, OPA Gatekeeper) layer on top** — PSA is the floor; other engines can be stricter but must not weaken it.
+
+## Sanitization rules
+
+- Never request kubeconfig contents or apiserver audit log access.
+- Replace identifiable namespace names and pod names with placeholders unless the user provides them.
+- Do not print pod environment variables, init container args, or volume secret content.

package/skills/kubernetes/kubernetes-pod-security-admission-review/references/official-sources.md

@@ -0,0 +1,26 @@
+# Official Sources
+
+Load these only when needed:
+
+- [Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) — use as the entry point. Covers labels, modes, version pinning, and the admission controller behavior.
+- [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) — use for the exact field-level requirements of `privileged`, `baseline`, and `restricted` profiles.
+- [Enforce Pod Security Standards via namespace labels](https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/) — use for the recommended rollout pattern (`warn` → `audit` → `enforce`).
+- [Enforce Pod Security Standards by configuring the built-in admission controller](https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/) — use for the cluster-wide `AdmissionConfiguration` syntax and exemption rules.
+- [Migrating from PodSecurityPolicy](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/) — use when the cluster is moving from PSP to PSA.
+- [Kubernetes Security Checklist](https://kubernetes.io/docs/concepts/security/security-checklist/) — use for the broader security context that PSA fits into (RBAC, NetworkPolicy, secrets, etc.).
+- [Configure a Security Context for a Pod or Container](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) — use when reviewing per-pod `securityContext` hardening (the actual fields PSA evaluates).
+- [seccomp profile for a container](https://kubernetes.io/docs/tutorials/security/seccomp/) — use for `RuntimeDefault` vs `Localhost` profile semantics that the restricted profile requires.
+- [Kubernetes API audit logs](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/) — use to find admission decisions when PSA mode is `audit`.
+
+## Grounded insights worth carrying into the skill
+
+- Pod Security Admission was introduced in 1.22 (alpha), promoted to beta in 1.23, and shipped stable in 1.25 — replacing the deprecated PodSecurityPolicy in the same release. Any cluster running 1.25 or later does not have PSP available.
+- Three profiles enforce a fixed set of pod spec constraints: `privileged` (none), `baseline` (deny known escalations), `restricted` (current best-practice hardening). A namespace can have a different profile per mode (`enforce`, `audit`, `warn`).
+- The most common rollout pattern is: set `warn` and `audit` to the target profile, observe admission warnings and audit log violations, fix workloads, then promote `enforce` to the target profile. This avoids breaking running workloads at flip time.
+- A namespace with no PSA label inherits the cluster default. The Kubernetes default is `privileged` unless the cluster admin set a stricter default in `AdmissionConfiguration`. Many production clusters silently run with privileged-equivalent admission because no label was set.
+- Profile semantics evolve across Kubernetes versions. The `enforce-version`, `audit-version`, `warn-version` labels pin profile semantics to a specific Kubernetes minor. Without pinning, a cluster upgrade can suddenly reject pods that previously admitted. Pinning is recommended.
+- Exemptions via `AdmissionConfiguration` (cluster-wide) bypass PSA entirely for the matched username, runtime class, or namespace. These are the broadest escape hatches and should be reviewed regularly. Per-namespace label exemptions (`pod-security.kubernetes.io/enforce: privileged`) are scoped to one namespace and easier to audit.
+- The restricted profile requires `runAsNonRoot: true`, `runAsUser != 0`, `allowPrivilegeEscalation: false`, no `capabilities.add` other than `NET_BIND_SERVICE`, `seccompProfile.type: RuntimeDefault` or `Localhost`, no host namespaces, no host paths, no `hostPort`, and no privileged or unsafe sysctls. Many off-the-shelf operators do not meet this.
+- Kyverno and OPA Gatekeeper can layer on top of PSA — they evaluate after PSA admission. This means a Kyverno policy that allows what PSA denies cannot rescue the pod; PSA's denial is final. Conversely, Kyverno can deny what PSA allows, providing a stricter-than-PSA layer.
+- The `kubectl-psp-to-psa` plugin (community-maintained) translates PSP definitions into the closest equivalent PSA labels. The translation is lossy when PSPs encoded per-pod constraints (e.g., specific `runAsUser` ranges).
+- `system:masters` group bypasses all admission controllers including PSA. Only the cluster-control-plane bootstrap should hold this; never bind real workloads to it.

package/skills/kubernetes/kubernetes-pod-security-admission-review/references/workflow-and-output.md

@@ -0,0 +1,129 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Identify the target scope
+
+PSA configuration lives in two places:
+
+1. **Per-namespace labels** — `pod-security.kubernetes.io/<mode>: <profile>` and `pod-security.kubernetes.io/<mode>-version: <version>`.
+2. **Cluster `AdmissionConfiguration`** — applies a default profile to namespaces that don't carry a label, and exempts specific namespaces, users, or runtime classes globally.
+
+Confirm which scope the review covers — a namespace label change is reversible by flipping the label; a cluster `AdmissionConfiguration` change requires control-plane access and a kube-apiserver restart.
+
+Reference: [Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) and [Enforce standards via namespace labels](https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/).
+
+### Step 2 — Identify the active profile and mode
+
+Three profiles, defined in [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/):
+
+1. **`privileged`** — unrestricted. No security context constraints. Equivalent to no admission control. Appropriate ONLY for system-level workloads (CNI, CSI drivers, monitoring agents).
+2. **`baseline`** — minimally restrictive. Disallows known privilege escalations. Allows most legitimate application workloads with minimal modification. Recommended floor for application namespaces.
+3. **`restricted`** — heavily restricted, follows current pod hardening best practices. Requires `runAsNonRoot: true`, `seccompProfile: RuntimeDefault`, no capabilities except `NET_BIND_SERVICE`, no host paths or host network, etc.
+
+Three modes, applied via labels:
+
+1. **`enforce`** — admission denied on violation. Pods that violate are rejected.
+2. **`audit`** — admission allowed; violation recorded in API server audit log.
+3. **`warn`** — admission allowed; violation returned to the user as a warning header (visible in `kubectl apply` output).
+
+Each mode/profile combination can have an independent version pin: `pod-security.kubernetes.io/enforce-version: v1.30`.
+
+### Step 3 — Audit profile-mode combinations
+
+Common configurations and their findings:
+
+- **`enforce: restricted`** — production-tier hardening. Verify all running pods admit; otherwise, the next pod restart will fail.
+- **`enforce: baseline`, `audit: restricted`, `warn: restricted`** — common migration pattern. Hard floor at baseline, with restricted violations surfaced for cleanup.
+- **`enforce: baseline`** alone — application namespace minimum. Confirm PSP-equivalent constraints are not assumed by other tooling.
+- **`enforce: privileged`** — only acceptable for system namespaces with documented justification.
+- **No PSA labels at all** — namespace falls back to cluster default. **Critical finding** if cluster default is `privileged` (the Kubernetes default unless changed).
+- **`audit` and/or `warn` set but no `enforce`** — security violations are logged, not blocked. Useful as observability but not as control.
+
+### Step 4 — Check whether existing workloads would still admit
+
+Before flipping a namespace from `baseline` to `restricted`, verify every running pod meets the stricter profile. Use `--dry-run=server` to ask the API server to evaluate without applying:
+
+```shell
+kubectl label namespace <ns> pod-security.kubernetes.io/enforce=restricted --overwrite --dry-run=server
+```
+
+This returns warnings for any pod that would be rejected. Review those pods before applying the label.
+
+Alternative: set `warn: restricted` first, watch for warnings in apply outputs and audit logs, fix workloads, then promote to `enforce: restricted`.
+
+Stress-tests:
+
+- Pods with `securityContext.runAsUser: 0` — restricted profile rejects.
+- Pods with `securityContext.privileged: true` — baseline AND restricted reject.
+- Pods with `securityContext.allowPrivilegeEscalation: true` — restricted rejects (baseline allows by default).
+- Pods with `volumes.hostPath` — baseline rejects (only specific paths allowed).
+- Pods with `securityContext.capabilities.add` containing anything beyond `NET_BIND_SERVICE` — restricted rejects.
+- Pods with `securityContext.seccompProfile` not set or set to `Unconfined` — restricted rejects (must be `RuntimeDefault` or `Localhost`).
+
+### Step 5 — Audit version pinning
+
+`enforce-version`, `audit-version`, `warn-version` pin the profile semantics to a specific Kubernetes minor. Findings:
+
+- **No version pin** — profile follows cluster's Kubernetes version. Each upgrade may tighten requirements.
+- **`*-version: latest`** — explicitly tracks the latest profile. Same risk as no pin but with more honesty.
+- **`*-version: v1.24`** on a 1.30 cluster — pinned to an old, less strict version. May allow workloads the current docs say should be denied.
+
+Recommended: pin to the cluster's current minor (`v1.30` on a 1.30 cluster) and explicitly bump the pin during cluster upgrade reviews.
+
+### Step 6 — Audit cluster-level exemptions
+
+`AdmissionConfiguration` exemptions:
+
+```yaml
+exemptions:
+  usernames: ["system:admin"]
+  runtimeClasses: ["sandboxed"]
+  namespaces: ["kube-system"]
+```
+
+Findings:
+
+- `usernames` exemption with broad bindings — the exempted user can run any pod regardless of namespace label.
+- `runtimeClasses` exemption for non-sandboxed runtimes — exempts pods using that runtime class entirely.
+- `namespaces` exemption for `kube-system` and operator namespaces — common, but every operator should be reviewed for whether it actually needs to run pods that violate baseline.
+
+### Step 7 — Audit migration from PodSecurityPolicy
+
+PSP was removed in Kubernetes 1.25. If the user is migrating:
+
+- Use `kubectl-psp-to-psa` (or equivalent) to translate existing PSP definitions into PSA labels.
+- The translation is not always exact — PSP allowed per-Pod conditions; PSA is per-namespace.
+- Some PSP capabilities (e.g., specific `runAsUser` ranges, specific FSGroup ranges) cannot be expressed in PSA — Kyverno or OPA Gatekeeper is needed for these.
+- Verify the old PSP webhook is removed AFTER PSA is enforced — running both simultaneously can produce conflicting decisions.
+
+Reference: [Migrating from PodSecurityPolicy](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/).
+
+### Step 8 — Stress-test operational hygiene
+
+- Prefer `enforce: baseline` minimum for application namespaces; `enforce: restricted` for tiers without legacy workloads.
+- Prefer pinned `*-version` matching cluster minor.
+- Prefer namespace-by-namespace promotion (`warn` → `audit` → `enforce`) over cluster-wide flips.
+- Prefer per-workload `securityContext` hardening over namespace exemption when one workload needs special access.
+- Verify that other admission policies (Kyverno, OPA Gatekeeper) extend rather than weaken PSA — a downstream policy that allows what PSA denies still results in the pod being rejected by PSA first.
+
+## Output
+
+Return:
+
+- **target**: namespace, namespace set, or cluster `AdmissionConfiguration`,
+- **evidence level**: `live evidence` / `documentation-based` / `sanitized user evidence` / `inference`,
+- **active configuration**: profile and mode per scope, with version pin,
+- **admission impact**: which currently-running pods would be rejected at the proposed profile,
+- **exemption posture**: cluster-level exemptions and per-namespace label overrides,
+- **risk findings** (with severity: high / medium / low),
+- **safest next actions** with sample manifest changes and the recommended `warn` → `audit` → `enforce` rollout,
+- **rollback plan**: how to remove or weaken the label if running workloads break,
+- **assumptions and missing facts**.
+
+## Security notes
+
+- Never recommend `enforce: privileged` for an application namespace.
+- Never recommend removing the namespace PSA label without a documented replacement (cluster default or another admission engine).
+- Never recommend exempting a namespace cluster-wide without confirming the workloads inside cannot be hardened.
+- Do not print pod environment variables, init container args, or any pod content beyond the security context.

package/skills/kubernetes/kubernetes-pod-spec-review/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: kubernetes-pod-spec-review
+description: Use this skill when reviewing a Kubernetes Pod spec, Deployment spec, or StatefulSet spec for correctness, security posture, and production-readiness. Trigger on any request to audit, validate, or score a workload manifest.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# Kubernetes Pod Spec Review
+
+## Purpose
+
+Review Kubernetes Pod, Deployment, and StatefulSet specifications for probe correctness, resource QoS configuration, securityContext posture, image pull policy safety, secret consumption patterns, topology spread, and termination grace period alignment. Output a structured findings list with severity, evidence, and safe remediation steps — aligned with CKAD domain knowledge and production-readiness standards.
+
+## Lean operating rules
+
+- Check both `livenessProbe` and `readinessProbe`; flag missing probes as HIGH for Deployments receiving traffic. Flag aggressive `livenessProbe.failureThreshold` (<=2) that kills pods during GC pauses.
+- Review `resources.requests` and `resources.limits`; flag missing requests (unschedulable under pressure) as MEDIUM and flag CPU limits without requests as Burstable QoS risk.
+- Audit `securityContext` at both pod level (`runAsNonRoot`, `seccompProfile`) and container level (`allowPrivilegeEscalation: false`, `readOnlyRootFilesystem: true`, `capabilities.drop: [ALL]`).
+- Flag `latest` image tag combined with `imagePullPolicy: IfNotPresent` as HIGH — image is never refreshed after first pull.
+- Flag Secrets consumed via `envFrom.secretRef` (bulk-mount exposes all keys) as MEDIUM; recommend volume mounts or specific `env.valueFrom.secretKeyRef`.
+- Check `topologySpreadConstraints` for multi-replica Deployments; flag absence as MEDIUM (single AZ failure = full outage).
+- Review `terminationGracePeriodSeconds` against application drain time; flag default 30s for gRPC or database workloads as MEDIUM.
+- Label all findings as live evidence, documentation-based, or inference.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md)
+
+## Response minimum
+
+- Severity-labeled findings list (CRITICAL / HIGH / MEDIUM / LOW)
+- Evidence source for each finding
+- Specific field path that caused the finding (e.g., `spec.containers[0].livenessProbe`)
+- Recommended remediation with example YAML snippet
+- Overall production-readiness verdict

package/skills/kubernetes/kubernetes-pod-spec-review/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "kubernetes-pod-spec-review",
+  "name": "Kubernetes Pod Spec Review",
+  "type": "skill",
+  "provider": "kubernetes",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review Kubernetes Pod, Deployment, and StatefulSet specs for probe correctness, resource QoS, securityContext posture, image pull policy, secret consumption patterns, topology spread, and termination grace period against CKAD-aligned production-readiness standards.",
+  "source_type": "original",
+  "official_docs": [
+    "https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/",
+    "https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/",
+    "https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/",
+    "https://kubernetes.io/docs/concepts/security/pod-security-standards/",
+    "https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/",
+    "https://kubernetes.io/docs/concepts/workloads/controllers/deployment/"
+  ],
+  "security_notes": "Secrets mounted as environment variables appear in kubectl describe pod output and in /proc/self/environ, accessible to any process in the container. Root containers can write to host paths if hostPath volumes are present. Missing runAsNonRoot allows container breakout to node if combined with hostPath or privileged mode.",
+  "last_verified": "2026-05-02",
+  "path": "skills/kubernetes/kubernetes-pod-spec-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/kubernetes/kubernetes-pod-spec-review/references/workflow-and-output.md

@@ -0,0 +1,229 @@
+# Workflow and Output Contract
+
+## Review Workflow
+
+### Step 1 — Identify the workload type
+
+Determine whether the input is a Pod, Deployment, StatefulSet, DaemonSet, Job, or CronJob spec. The review scope differs:
+
+- **Pod / Deployment** — full probe, resource, securityContext, topology spread review
+- **StatefulSet** — same as Deployment plus PVC template review, ordered startup considerations
+- **DaemonSet** — probe review less critical; focus on host namespace usage, privileged mode, resource limits
+- **Job / CronJob** — no readiness probe required; focus on `activeDeadlineSeconds`, `backoffLimit`, resource limits
+
+### Step 2 — Probe review
+
+```yaml
+# Minimum production-ready probe configuration
+livenessProbe:
+  httpGet:
+    path: /healthz
+    port: 8080
+  initialDelaySeconds: 15
+  periodSeconds: 20
+  failureThreshold: 3       # >=3 to tolerate GC pauses
+  timeoutSeconds: 5
+
+readinessProbe:
+  httpGet:
+    path: /ready
+    port: 8080
+  initialDelaySeconds: 10
+  periodSeconds: 10
+  failureThreshold: 3
+  timeoutSeconds: 3
+
+startupProbe:               # required if startup > 30s
+  httpGet:
+    path: /healthz
+    port: 8080
+  failureThreshold: 30      # 30 * periodSeconds(10) = 300s max startup
+  periodSeconds: 10
+```
+
+**Flags:**
+- Missing `livenessProbe` on a long-running container — HIGH
+- Missing `readinessProbe` on a Deployment that receives traffic — HIGH
+- `livenessProbe.failureThreshold: 1` or `2` — HIGH (kills pod during GC pause)
+- `readinessProbe.initialDelaySeconds` < known startup time — HIGH (probe fails before app ready)
+- Missing `startupProbe` when app startup > 30s — MEDIUM
+
+### Step 3 — Resource QoS review
+
+```yaml
+resources:
+  requests:
+    cpu: "250m"
+    memory: "256Mi"
+  limits:
+    cpu: "500m"    # CPU limits cause throttling; consider removing if not required
+    memory: "512Mi"
+```
+
+**QoS tier resolution:**
+
+| Condition | QoS Class | Risk |
+|-----------|-----------|------|
+| `requests == limits` for all containers | Guaranteed | Lowest eviction priority |
+| `requests` set, `limits` not equal | Burstable | Evicted under node pressure |
+| No `requests`, no `limits` | BestEffort | First evicted under any pressure |
+
+**Flags:**
+- No `resources.requests` — MEDIUM (BestEffort QoS, evicted first)
+- `limits.memory` without `requests.memory` — MEDIUM (Burstable, OOM killed under node pressure)
+- `limits.cpu` set to a value significantly lower than typical usage — MEDIUM (CPU throttle)
+- Critical workload without Guaranteed QoS (`requests != limits`) — MEDIUM
+
+### Step 4 — securityContext review
+
+```yaml
+# Pod-level
+spec:
+  securityContext:
+    runAsNonRoot: true
+    runAsUser: 1000
+    seccompProfile:
+      type: RuntimeDefault   # K8s 1.22+
+
+# Container-level
+containers:
+  - name: app
+    securityContext:
+      allowPrivilegeEscalation: false
+      readOnlyRootFilesystem: true
+      capabilities:
+        drop:
+          - ALL
+        add: []              # only add specific caps if truly required
+```
+
+**Flags:**
+- Missing `runAsNonRoot: true` — HIGH (runs as root by default)
+- `allowPrivilegeEscalation: true` or missing — HIGH
+- Missing `readOnlyRootFilesystem: true` — MEDIUM (writable filesystem enables malware persistence)
+- Missing `capabilities.drop: [ALL]` — MEDIUM
+- `privileged: true` — CRITICAL (host-level access)
+- Missing `seccompProfile` — LOW (defaults to unconfined syscall access)
+
+### Step 5 — Image pull policy and tag review
+
+```yaml
+# Correct for digest-pinned images
+image: myregistry/myapp@sha256:abc123...
+imagePullPolicy: IfNotPresent
+
+# Correct for latest or mutable tags
+image: myregistry/myapp:latest
+imagePullPolicy: Always
+```
+
+**Flags:**
+- `latest` tag with `imagePullPolicy: IfNotPresent` — HIGH (stale image after first pull)
+- `latest` tag at all — MEDIUM (non-deterministic deployments)
+- No image digest pinning for critical workloads — LOW
+
+### Step 6 — Secret and ConfigMap consumption review
+
+```yaml
+# PREFERRED: Volume mount (secret not in env, not in describe output)
+volumes:
+  - name: db-creds
+    secret:
+      secretName: db-credentials
+containers:
+  - volumeMounts:
+      - name: db-creds
+        mountPath: /etc/secrets
+        readOnly: true
+
+# ACCEPTABLE: Specific env var from secret key
+env:
+  - name: DB_PASSWORD
+    valueFrom:
+      secretKeyRef:
+        name: db-credentials
+        key: password
+
+# AVOID: Bulk-mount exposes ALL secret keys including unused ones
+envFrom:
+  - secretRef:
+      name: db-credentials
+```
+
+**Flags:**
+- `envFrom.secretRef` bulk-mount — MEDIUM (all keys exposed to process env and kubectl describe)
+- `env.valueFrom.secretKeyRef` — ACCEPTABLE (only named key exposed)
+- Secret as environment variable (either method) — NOTE (appears in /proc/self/environ)
+
+### Step 7 — Topology spread and affinity review
+
+```yaml
+# Preferred: topology spread (K8s 1.19+)
+topologySpreadConstraints:
+  - maxSkew: 1
+    topologyKey: topology.kubernetes.io/zone
+    whenUnsatisfiable: DoNotSchedule
+    labelSelector:
+      matchLabels:
+        app: myapp
+
+# Also check podAntiAffinity for legacy configs
+affinity:
+  podAntiAffinity:
+    preferredDuringSchedulingIgnoredDuringExecution:
+      - weight: 100
+        podAffinityTerm:
+          topologyKey: kubernetes.io/hostname
+          labelSelector:
+            matchLabels:
+              app: myapp
+```
+
+**Flags:**
+- Multi-replica Deployment (>1 replica) with no `topologySpreadConstraints` and no `podAntiAffinity` — MEDIUM
+- `topologySpreadConstraints` present but `topologyKey: kubernetes.io/hostname` only (no zone spread) — LOW
+- `whenUnsatisfiable: ScheduleAnyway` on a critical workload — LOW (spread not enforced)
+
+### Step 8 — Termination grace period review
+
+```yaml
+spec:
+  terminationGracePeriodSeconds: 60  # increase for gRPC, database draining
+```
+
+**Flags:**
+- Default 30s for gRPC servers with long-lived streams — MEDIUM
+- Default 30s for database pods (PostgreSQL, MySQL) that need checkpoint time — MEDIUM
+- `terminationGracePeriodSeconds: 0` — HIGH (immediate SIGKILL, no graceful shutdown)
+
+---
+
+## Output Format
+
+Return findings in this structure:
+
+### Finding: `<short title>`
+
+| Field | Value |
+|-------|-------|
+| Severity | CRITICAL / HIGH / MEDIUM / LOW |
+| Field path | `spec.containers[0].livenessProbe` |
+| Evidence | documentation-based / live evidence / inference |
+| Description | What is wrong and why it matters |
+| Remediation | YAML snippet or command |
+
+---
+
+### Overall Verdict
+
+| Category | Status |
+|----------|--------|
+| Probes | PASS / FAIL |
+| Resource QoS | PASS / FAIL |
+| Security context | PASS / FAIL |
+| Image hygiene | PASS / FAIL |
+| Secret consumption | PASS / FAIL |
+| Topology spread | PASS / FAIL |
+| Termination grace | PASS / FAIL |
+
+**Production-ready:** YES / NO / CONDITIONAL (list conditions)

package/skills/kubernetes/kubernetes-rbac-review/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: kubernetes-rbac-review
+description: Use this skill for Kubernetes RBAC, Role, ClusterRole, RoleBinding, ClusterRoleBinding, ServiceAccount, workload identity, or least-privilege review tasks. Trigger when the user asks whether cluster access is too broad, how to grant workload permissions safely, or how to audit RBAC state.
+metadata:
+  author: github: Raishin
+  version: 0.1.0
+---
+
+# Kubernetes RBAC Review
+
+## Purpose
+
+Review Kubernetes RBAC objects — Roles, ClusterRoles, RoleBindings, ClusterRoleBindings, and ServiceAccounts — against least privilege, namespace scope minimization, and operational safety.
+
+## Lean operating rules
+
+- Prefer live cluster evidence (`kubectl auth can-i`, `kubectl get rolebinding`, audit logs) when the active client exposes it; otherwise fall back to official Kubernetes documentation and sanitized user evidence.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge cluster-scoped access granted to workloads that only need namespace-scoped access.
+- Challenge wildcard verbs (`*`), wildcard resources (`*`), and wildcard API groups (`*`) unless explicitly justified.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+
+## References
+
+Load these only when needed:
+
+- [Evidence path and tooling](references/mcp-and-evidence.md) — use when choosing live cluster evidence, confirming MCP capability, or switching to documentation mode.
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when you need the detailed Kubernetes documentation list or source notes.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/kubernetes/kubernetes-rbac-review/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "kubernetes-rbac-review",
+  "name": "Kubernetes RBAC Review",
+  "type": "skill",
+  "provider": "kubernetes",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Kubernetes Roles, ClusterRoles, RoleBindings, ClusterRoleBindings, and ServiceAccounts for least-privilege, namespace-scope, and workload identity safety.",
+  "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/access-authn-authz/authorization/",
+    "https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/"
+  ],
+  "security_notes": "Do not recommend ClusterAdmin or wildcard bindings unless explicitly justified. Prefer namespace-scoped Roles over ClusterRoles for workloads that do not need cluster-wide access. Do not auto-mount service account tokens unless the workload requires API server access.",
+  "last_verified": "2026-05-01",
+  "path": "skills/kubernetes/kubernetes-rbac-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/kubernetes/kubernetes-rbac-review/references/mcp-and-evidence.md

@@ -0,0 +1,34 @@
+# Evidence Path and Tooling
+
+## Evidence path
+
+1. Prefer live cluster evidence when the active client exposes relevant Kubernetes MCP capabilities or a working `kubectl` context.
+2. Fall back to official Kubernetes documentation when live inspection is unavailable, incomplete, or unsafe.
+3. Ask only for sanitized RBAC YAML or `kubectl` output when current-state proof matters.
+4. Label conclusions as `live evidence`, `documentation-based`, `sanitized user evidence`, or `inference`.
+
+## Useful live-evidence commands
+
+```shell
+# List all RoleBindings in a namespace
+kubectl get rolebindings -n <namespace> -o yaml
+
+# List all ClusterRoleBindings
+kubectl get clusterrolebindings -o yaml
+
+# Check effective permissions for a ServiceAccount
+kubectl auth can-i --list --as=system:serviceaccount:<namespace>:<sa-name>
+
+# Check a specific verb/resource
+kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<namespace>:<sa-name> -n <namespace>
+
+# Describe a Role or ClusterRole
+kubectl describe role <name> -n <namespace>
+kubectl describe clusterrole <name>
+```
+
+## Platform-agnostic execution
+
+- Keep examples neutral with placeholders until the user's cluster context and toolchain are known.
+- Do not request kubeconfig files, bearer tokens, service account JWT tokens, or cloud-provider credentials in chat.
+- If a Kubernetes MCP server or kubectl is unavailable, say so and fall back to reviewing sanitized YAML provided by the user.

package/skills/kubernetes/kubernetes-rbac-review/references/official-sources.md

@@ -0,0 +1,22 @@
+# Official Sources
+
+Load these only when needed:
+
+- [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) — use for Role, ClusterRole, RoleBinding, ClusterRoleBinding structure, aggregation rules, default roles, and `kubectl auth` usage.
+- [RBAC Good Practices](https://kubernetes.io/docs/concepts/security/rbac-good-practices/) — use for least privilege, wildcard cautions, privilege escalation paths, impersonation risks, and workload namespace isolation.
+- [Authorization Overview](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) — use when confirming how Kubernetes evaluates requests and which authorizers are stacked.
+- [Configure Service Accounts for Pods](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) — use for `automountServiceAccountToken`, dedicated ServiceAccount patterns, and token projection.
+- [Kubernetes Security Checklist](https://kubernetes.io/docs/concepts/security/security-checklist/) — use for a holistic posture check covering RBAC alongside admission, network policies, and pod security.
+- [Bound Service Account Tokens](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-tokens) — use when reviewing projected token lifetimes, audience binding, and migration from legacy auto-mounted tokens.
+
+## Grounded insights worth carrying into the skill
+
+- Kubernetes RBAC is additive: there are no deny rules. Any binding that grants a permission cannot be overridden by another binding.
+- `pods/exec` and `pods/attach` are equivalent to remote-shell access on any pod; treat both as high-severity grants requiring explicit justification.
+- `pods/portforward` tunnels arbitrary TCP to pod ports; treat as high-severity for database and internal-service workloads.
+- `nodes/proxy` grants proxy access to the kubelet API on every node — this is effectively cluster-admin for node-level operations and is rarely justified for any non-system workload.
+- `secrets` `get`/`list` access at ClusterRole scope means reading every secret in every namespace — almost always over-privileged for a workload.
+- `escalate` on roles/clusterroles, `bind` on bindings, and `impersonate` on users/groups/serviceaccounts are Kubernetes' three dedicated privilege-escalation verbs. Any Role that grants these is high severity regardless of other verb restrictions — they allow the holder to exceed their own permission set.
+- The `system:masters` group bypasses all RBAC checks, including admission webhooks; never bind real workloads to it.
+- Aggregated ClusterRoles (`aggregationRule`) inherit rules from any ClusterRole that matches the label selector — third-party operators can silently expand them.
+- Setting `automountServiceAccountToken: false` on the ServiceAccount (or the Pod spec) is the correct default for workloads that do not call the Kubernetes API.