skills/vibe-kubernetes/references/kubernetes-platform-audit.md

# Kubernetes Platform Audit

## Operation

Inspect the named boundary and report supported findings. Do not edit product code. Include concrete evidence, impact, the owning source, one remediation direction and a meaningful validation route. Severity follows actual impact, not a category example.

## Goal and scope

Audit a Kubernetes workload as a deployable runtime contract: rollout, probes, scheduling, networking, storage, policy, and operator recovery.

## Domain invariants

- Rendered workload identity, selectors, labels, ports, service accounts, configuration references, and ownership are internally consistent for the target environment.
- Startup, readiness, and liveness probes test distinct properties and do not create restart loops, premature traffic, or indefinite unready capacity.
- Rolling update parameters, progress deadline, replica count, PodDisruptionBudget, preStop/SIGTERM handling, and termination grace preserve required availability and drain semantics.
- Resource requests describe schedulable baseline demand; limits and autoscaling signals do not create CPU throttling, memory eviction, or feedback loops that violate the service SLO.
- Service/Ingress/Gateway, DNS, NetworkPolicy, proxy headers, TLS, and health paths form one reachable and least-privilege network contract.
- Stateful identity, access mode, storage class, volume binding, reclaim behavior, backup/restore, and rescheduling semantics match the application's consistency model.
- RBAC, service accounts, security context, capabilities, seccomp, filesystem mode, image identity, and secret/config exposure follow least privilege.
- Environment overlays and generated manifests are reviewed after render; a base template alone is not deployment evidence.

## Audit method

1. Render the exact target overlay/chart and map workload → ReplicaSet/Pod → Service/Ingress → config/secret → storage/policy dependencies.
2. Trace pod admission, startup, readiness, traffic, SIGTERM/drain, restart, rollout, rollback, and node disruption paths.
3. Check scheduler fit, requests/limits, priority/affinity/topology spread, HPA inputs, stabilization, and minimum healthy capacity.
4. Verify service selectors/ports, DNS names, TLS ownership, NetworkPolicy directions, and trusted proxy boundaries.
5. For stateful work, inspect attach/mount/recovery/backup and data-consistency behavior after reschedule or partial failure.

## Priority model

- **P0:** cluster or service outage, privilege exposure, data loss, invalid rollout, or unrecoverable stateful workload failure.
- **P1:** a material scheduling, probe, policy, resource, rollout, or capacity defect.
- **P2:** a lower-risk but concrete operability, efficiency, or resilience issue.