@raishin/vanguard-frontier-agentic 1.2.0 → 1.4.0

package/skills/kubernetes/kubernetes-maestro/references/workflow-and-output.md

@@ -0,0 +1,206 @@
+# Routing table and domain taxonomy
+
+Use this reference when classifying a task or selecting the right specialist(s).
+
+## Routing table
+
+| Signal keywords | Agent ID | Domain | Live-guard? |
+|---|---|---|---|
+| RBAC, Role, ClusterRole, RoleBinding, ClusterRoleBinding, ServiceAccount, can-i, least privilege, permissions | kubernetes-rbac-review-agent | RBAC review | No |
+| apply RBAC, kubectl apply role, grant permission, bind ClusterRole, create RoleBinding, escalate verb, add permissions | kubernetes-live-rbac-mutation-guard-agent | Live RBAC mutation | YES |
+| PSA, PodSecurityAdmission, pod-security label, enforce/audit/warn, restricted profile, baseline profile, privileged profile, PSP migration, namespace label | kubernetes-psa-review-agent | Pod security admission review | No |
+| Kyverno, ClusterPolicy, kyverno policy, PolicyException, mutate rule, generate rule, image verify, background scan, failureAction | kyverno-policy-review-agent | Kyverno policy review | No |
+| apply Kyverno policy, kubectl apply cpol, change failureAction, delete ClusterPolicy, add PolicyException, ValidatingAdmissionPolicy | kubernetes-live-admission-policy-guard-agent | Live admission policy mutation | YES |
+| IRSA, workload identity, serviceAccountToken, OIDC trust, pod identity, azure workload identity, GKE WI, annotate serviceaccount, projected token, eks.amazonaws.com | kubernetes-workload-identity-review-agent | Workload identity review | No |
+| Istio, ambient mesh, waypoint, ztunnel, AuthorizationPolicy, PeerAuthentication, mTLS, RequestAuthentication, VirtualService, DestinationRule, HBONE | istio-ambient-mesh-review-agent | Istio mesh review | No |
+| apply AuthorizationPolicy, apply PeerAuthentication, change mTLS, delete DENY policy, enable PERMISSIVE, istioctl apply | kubernetes-live-mesh-policy-guard-agent | Live mesh policy mutation | YES |
+| Cilium, CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy, NetworkPolicy, ClusterMesh, egress gateway, Hubble, L7 policy, toCIDRSet | cilium-network-policy-review-agent | Cilium network policy review | No |
+| apply CiliumNetworkPolicy, kubectl apply cnp, delete default-deny, change toCIDRSet, egress gateway policy | kubernetes-live-network-policy-guard-agent | Live network policy mutation | YES |
+| Argo CD, ArgoCD, Application, AppProject, ApplicationSet, sync window, argocd sync, gitops, app of apps, ApplicationSet | argocd-gitops-review-agent | Argo CD GitOps review | No |
+| argocd app sync, sync production, delete sync-window, expand AppProject, enable auto-sync, ApplicationSet cluster generator | kubernetes-live-argocd-sync-guard-agent | Live Argo CD sync guard | YES |
+| OpenTelemetry, OTEL, otelcol, collector, pipeline, receiver, processor, exporter, Instrumentation CR, TargetAllocator, memory_limiter | opentelemetry-collector-config-review-agent | OpenTelemetry collector review | No |
+| cert-manager, ClusterIssuer, Issuer, CertificateRequest, CertificateRequestPolicy, approver-policy, trust-manager, Bundle, ConfigMapBundle, certificate renewal, TLS cert K8s, mTLS cert, SPIFFE, cert-manager webhook | cert-manager-issuer-trust-review-agent | PKI K8s review | No |
+
+## Domain taxonomy
+
+| Domain | Keywords and signals |
+|---|---|
+| `rbac` | Role, ClusterRole, RoleBinding, ClusterRoleBinding, ServiceAccount, can-i, RBAC, least privilege, permission, verb, subject |
+| `admission-security` | PSA, PodSecurityAdmission, pod-security label, enforce, audit, warn, restricted, baseline, privileged, PSP migration, Kyverno, ClusterPolicy, PolicyException, mutate, generate, image verify |
+| `workload-identity` | IRSA, workload identity, serviceAccountToken, OIDC, pod identity, azure workload identity, GKE WI, projected token, bound service account |
+| `mesh` | Istio, ambient mesh, waypoint, ztunnel, AuthorizationPolicy, PeerAuthentication, mTLS, RequestAuthentication, VirtualService, DestinationRule, Envoy |
+| `network-policy` | Cilium, CiliumNetworkPolicy, NetworkPolicy, ClusterMesh, Hubble, egress gateway, L7 policy, CNI |
+| `gitops` | Argo CD, ArgoCD, Application, AppProject, ApplicationSet, sync window, app of apps, GitOps, deployment sync |
+| `observability` | OpenTelemetry, OTEL, otelcol, collector, pipeline, receiver, processor, exporter, Instrumentation CR, TargetAllocator, tracing, metrics, logs |
+| `pki` | cert-manager, ClusterIssuer, Issuer, CertificateRequest, CertificateRequestPolicy, approver-policy, trust-manager, Bundle, ConfigMapBundle, certificate renewal, TLS cert, SPIFFE, cert-manager webhook |
+| `live-guard` | apply RBAC live, apply admission policy live, change mTLS live, apply network policy live, argocd sync production, requires human gate, production mutation |
+
+## Specialist reference
+
+### RBAC
+
+| Agent | Domain | Use when… |
+|---|---|---|
+| `kubernetes-rbac-review-agent` | RBAC review | Reviewing Roles, ClusterRoles, bindings, ServiceAccount permissions, or running kubectl auth can-i audit for least privilege |
+| `kubernetes-live-rbac-mutation-guard-agent` | Live RBAC mutation | Applying new RBAC objects, granting permissions, binding ClusterRoles, or escalating verbs in a live cluster — gate required |
+
+### Admission security
+
+| Agent | Domain | Use when… |
+|---|---|---|
+| `kubernetes-psa-review-agent` | Pod security admission | Reviewing PSA labels on namespaces, enforcing/auditing/warning against restricted or baseline profiles, or planning PSP migration |
+| `kyverno-policy-review-agent` | Kyverno policy review | Reviewing or authoring Kyverno ClusterPolicies, mutate/generate/verify rules, PolicyExceptions, or running background scan analysis |
+| `kubernetes-live-admission-policy-guard-agent` | Live admission policy mutation | Applying or deleting Kyverno ClusterPolicies, changing failureAction, or adding PolicyExceptions in a live cluster — gate required |
+
+### Workload identity
+
+| Agent | Domain | Use when… |
+|---|---|---|
+| `kubernetes-workload-identity-review-agent` | Workload identity review | Reviewing IRSA annotations, OIDC trust relationships, projected serviceAccountToken usage, Azure Workload Identity, or GKE Workload Identity setup |
+
+### Mesh
+
+| Agent | Domain | Use when… |
+|---|---|---|
+| `istio-ambient-mesh-review-agent` | Istio mesh review | Reviewing Istio ambient mesh waypoint config, AuthorizationPolicy, PeerAuthentication, mTLS mode, VirtualService/DestinationRule, or RequestAuthentication |
+| `kubernetes-live-mesh-policy-guard-agent` | Live mesh policy mutation | Applying or deleting AuthorizationPolicy or PeerAuthentication, changing mTLS mode, or enabling PERMISSIVE mode in a live cluster — gate required |
+
+### Network policy
+
+| Agent | Domain | Use when… |
+|---|---|---|
+| `cilium-network-policy-review-agent` | Cilium network policy review | Reviewing CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy, ClusterMesh config, Hubble observability, or L7 policy rules |
+| `kubernetes-live-network-policy-guard-agent` | Live network policy mutation | Applying or deleting CiliumNetworkPolicy, removing default-deny rules, changing toCIDRSet, or modifying egress gateway config in a live cluster — gate required |
+
+### GitOps
+
+| Agent | Domain | Use when… |
+|---|---|---|
+| `argocd-gitops-review-agent` | Argo CD GitOps review | Reviewing ArgoCD Application/AppProject/ApplicationSet config, sync windows, app-of-apps patterns, or GitOps reconciliation strategy |
+| `kubernetes-live-argocd-sync-guard-agent` | Live Argo CD sync guard | Triggering an argocd app sync to production, deleting sync windows, expanding AppProject scope, or enabling auto-sync on a production app — gate required |
+
+### Observability
+
+| Agent | Domain | Use when… |
+|---|---|---|
+| `opentelemetry-collector-config-review-agent` | OpenTelemetry review | Reviewing OpenTelemetry Collector pipelines, receiver/processor/exporter configs, Instrumentation CRs, or TargetAllocator setup for Kubernetes workloads |
+
+### PKI
+
+| Agent | Domain | Use when… |
+|---|---|---|
+| `cert-manager-issuer-trust-review-agent` | PKI K8s review | Reviewing cert-manager ClusterIssuer/Issuer scope, CertificateRequestPolicy coverage, Certificate SAN and duration risks, trust-manager bundle distribution, or SPIFFE trust domain integration |
+
+**Cross-layer note:** cert-manager is a certificate lifecycle controller, not a CA. When the task involves the cloud Private CA configuration (template ARN, IRSA/Managed Identity scope, CRL reachability, CA hierarchy), escalate to the relevant cloud maestro in parallel: `aws-private-ca-issuer-review-agent` (AWS), `azure-keyvault-certificate-issuer-review-agent` (Azure), `oci-certificates-issuer-review-agent` (OCI). See `docs/pki-cert-manager-agent-guide.md` for multi-agent PKI scenarios.
+
+## Multi-domain dispatch examples
+
+### Example 1: Namespace security posture + Kyverno policies
+
+**User request:** "Review our namespace security posture AND check our Kyverno policies."
+
+**Routing:**
+```
+Route: kubernetes-psa-review-agent, kyverno-policy-review-agent
+Reason: Task spans PSA namespace label enforcement and Kyverno policy review — two separate admission security domains.
+Mode: parallel (2)
+```
+
+`kubernetes-psa-review-agent` reviews PSA enforce/audit/warn labels across namespaces and identifies any missing or permissive labels; `kyverno-policy-review-agent` reviews ClusterPolicies for correctness, failureAction settings, and background scan results.
+
+---
+
+### Example 2: Service mesh and network policies audit
+
+**User request:** "Audit our service mesh and network policies."
+
+**Routing:**
+```
+Route: istio-ambient-mesh-review-agent, cilium-network-policy-review-agent
+Reason: Task spans Istio ambient mesh review and Cilium network policy review — two distinct network security domains.
+Mode: parallel (2)
+```
+
+`istio-ambient-mesh-review-agent` reviews waypoint configuration, AuthorizationPolicy, PeerAuthentication, and mTLS posture; `cilium-network-policy-review-agent` reviews CiliumNetworkPolicy default-deny posture, toCIDRSet rules, and ClusterMesh semantics.
+
+---
+
+### Example 3: RBAC, workload identity, and PSA for prod namespace
+
+**User request:** "Check RBAC, workload identity, and PSA for our prod namespace."
+
+**Routing:**
+```
+Route: kubernetes-rbac-review-agent, kubernetes-workload-identity-review-agent, kubernetes-psa-review-agent
+Reason: Task spans RBAC least-privilege review, OIDC workload identity trust, and Pod Security Admission labels — three clearly identified domains.
+Mode: parallel (3)
+```
+
+All three specialists run in parallel: `kubernetes-rbac-review-agent` audits Role/ClusterRole bindings and verbs for the prod namespace; `kubernetes-workload-identity-review-agent` reviews IRSA or workload identity annotations and OIDC trust policy scope; `kubernetes-psa-review-agent` verifies PSA enforce label, profile, and version pinning on the prod namespace.
+
+---
+
+### Example 4: ArgoCD AppProject blast-radius + Kyverno policies before prod deploy
+
+**User request:** "Review ArgoCD AppProject blast-radius and Kyverno policies before prod deploy."
+
+**Routing:**
+```
+Route: argocd-gitops-review-agent, kyverno-policy-review-agent
+Reason: Task spans Argo CD AppProject scope and Kyverno admission policy review — two distinct GitOps and admission security domains.
+Mode: parallel (2)
+```
+
+`argocd-gitops-review-agent` reviews the AppProject `sourceRepos`, `destinations`, `clusterResourceWhitelist`, and sync impersonation posture; `kyverno-policy-review-agent` reviews active ClusterPolicies for correctness and background scan violations that would block the deploy.
+
+---
+
+### Example 5: cert-manager setup + workload identity review
+
+**User request:** "Review our cert-manager ClusterIssuer config and the IRSA annotation on the cert-manager ServiceAccount."
+
+**Routing:**
+```
+Route: cert-manager-issuer-trust-review-agent, kubernetes-workload-identity-review-agent
+Reason: Task spans cert-manager PKI K8s config (ClusterIssuer scope, CertificateRequestPolicy) and IRSA workload identity trust for the cert-manager ServiceAccount.
+Mode: parallel (2)
+```
+
+`cert-manager-issuer-trust-review-agent` reviews ClusterIssuer scope, CertificateRequestPolicy coverage, Certificate SAN and duration risks, and trust-manager distribution; `kubernetes-workload-identity-review-agent` reviews the IRSA annotation, OIDC trust policy, and whether the role is scoped to minimum required actions.
+
+---
+
+### Live-guard gate example
+
+**User request:** "Apply the new ClusterRoleBinding for the payments service account in the prod cluster."
+
+**Routing:**
+```
+Route: kubernetes-live-rbac-mutation-guard-agent
+Reason: Applying a ClusterRoleBinding to a live production cluster is a live RBAC mutation — gate required.
+Mode: live-guard-gate
+```
+
+**STOP — Live-guard gate. Before this dispatch can proceed, you must provide:**
+
+1. **Blast-radius assessment:** Which namespaces, workloads, and users are affected by this ClusterRoleBinding? What is the scope of the verbs and resources being granted?
+2. **Rollback path:** What is the exact command to revoke this binding if it grants unintended access, and how long will rollback take?
+3. **Explicit written confirmation:** Type "I confirm I understand the blast radius and rollback path. Proceed."
+
+If you cannot supply a rollback path, route to `kubernetes-rbac-review-agent` first to develop a scoped binding with a documented revocation procedure.
+
+---
+
+## Live-guard gate protocol
+
+Before routing to any live-guard agent, surface all three and wait for explicit written confirmation:
+
+1. **Blast-radius assessment** — which resources, namespaces, workloads, or users are affected if this goes wrong?
+2. **Rollback path** — what is the tested recovery procedure, exact commands, and estimated recovery time?
+3. **Explicit confirmation** — "I confirm I understand the blast radius and rollback path. Proceed."
+
+If the user cannot supply a rollback path, recommend the corresponding review agent to develop the rollback path first before dispatching the live-guard agent.
+
+## Safety checklist reference
+
+Load [references/safety-checklist.md](safety-checklist.md) before any live-guard dispatch or when blast-radius assessment is required.

package/skills/kubernetes/kubernetes-pod-security-admission-review/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: kubernetes-pod-security-admission-review
+description: Use this skill for Kubernetes Pod Security Admission (PSA) review covering namespace labels for the three profiles (privileged, baseline, restricted), enforce/audit/warn modes, version pinning, and the migration path from deprecated PodSecurityPolicy. Trigger when the user asks whether a namespace label flip is safe, whether a workload meets a stricter profile, whether the audit/warn modes should be promoted to enforce, or whether an exemption is justified.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-05"
+  category: security
+---
+
+# Kubernetes Pod Security Admission Review
+
+## Purpose
+
+Review the Kubernetes Pod Security Admission posture: namespace labels for `pod-security.kubernetes.io/enforce`, `audit`, and `warn`, the chosen profile (`privileged`, `baseline`, `restricted`), version pinning, and exemptions. PSA replaced the deprecated PodSecurityPolicy in Kubernetes 1.25. It is the foundation for any admission-time security story — Kyverno, OPA Gatekeeper, and other policy engines layer on top of (or alongside) PSA, not as replacements.
+
+## Lean operating rules
+
+- Prefer live cluster evidence (`kubectl get namespaces --show-labels` plus `kubectl get pods -n <ns> -o yaml`) when the active client exposes it; otherwise fall back to official Kubernetes documentation and sanitized YAML.
+- Separate confirmed facts from inference. If namespace labels, cluster admission configuration, or running pod security context state was not queried, say so.
+- Treat **a production namespace with `enforce: privileged`** as a critical finding — the most permissive profile is enabled in a tier where nothing should be running with host access, privilege escalation, or capabilities.
+- Treat **a production namespace with no PSA label at all** as a critical finding — the cluster default applies, which is `privileged` unless the cluster admin set a different default in `AdmissionConfiguration`.
+- Challenge namespaces with `audit`/`warn` set but `enforce` missing — security violations are only logged, not blocked.
+- Challenge `enforce-version: latest` — every Kubernetes upgrade can change profile semantics; pin to a specific minor.
+- Challenge `kube-system` and operator namespaces excluded from PSA without documentation of which workloads require privileged access.
+- 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 evidence, confirming cluster admission configuration, or switching to documentation mode.
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying profile-by-profile stress checks, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when you need the detailed Kubernetes documentation list and grounded insights.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target (specific namespace, set of namespaces, or cluster default) and evidence level,
+- the active profile (`privileged` / `baseline` / `restricted`) and active mode (`enforce` / `audit` / `warn`),
+- whether currently-running pods would still admit at the proposed profile,
+- the exemption posture (cluster `AdmissionConfiguration` exemptions, namespace label override),
+- the safest next actions and rollback plan,
+- the assumptions or blockers that prevent stronger conclusions.

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,41 @@
+---
+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.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-05"
+  category: platform
+---
+
+# 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"
+}