Files
home-network-k3s-impl/platform/kyverno/admission
jakman85andClaude Opus 4.8 d9a80e5350 phase2-prep: per-component no-secret rollout + component hardening (author-first)
Prep only — nothing deployed; running cluster untouched.

Reconciliation graph (operator-approved Option A): author clusters/dev/rollout/
= 4 per-component Flux Kustomizations (kyverno->cilium->longhorn->monitoring,
monitoring dependsOn longhorn). Dev overlay $patch:delete's the monolithic base
platform/apps and adds ./rollout, so only the no-secret tier reconciles; the
secret-blocked components are simply not created until hand-offs arrive. The
no-secret tier carries no SOPS content, so it needs no sops-age key. prod is
untouched (still builds the monolith). Convergence path coded in (delete rollout/
+ the two deletes) — R-ENV-02 divergence flagged for architect review.

Component hardening via cluster-vars (prod keeps strict posture):
- KYVERNO_VALIDATION_ACTION Enforce->Audit(dev), _WEBHOOK_FAILURE_POLICY
  Fail->Ignore(dev), _ADMISSION_REPLICAS 3->1(dev); webhook namespaceSelector
  excludes system+platform namespaces.
- MONITORING_STORAGE_CLASS var; GRAFANA_ADMIN_SECRET var (dev ''=chart default);
  Alertmanager SMTP/secret deferred to Phase-4 with verbatim re-enable markers.

Cilium parity verified against the live CNI (no-op adopt). Validated:
kubectl kustomize dev/prod/all-components, envsubst->YAML parse, make -C ci gate PASS.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
2026-08-16 21:34:57 -05:00
..

In-cluster admission enforcement (scaffolding — Phase 2 / T-2.7)

Installs Kyverno and runs the same L0 policies as an in-cluster admission controller, so a non-conforming resource that somehow bypassed CI still cannot be admitted (defense in depth — docs/07, ADR-0011). Not applied in Phase 0 (no cluster exists yet); this is scaffolding wired up in task T-2.7.

Enforcement COMPLEMENTS, never REPLACES, behavior tests

A policy admitting a manifest is not proof the runtime behaves (docs/14 principle 1, R-TEST-01). Kyverno confirms a resource is shaped correctly; it does not prove default-deny actually blocks a packet, that the VPN kill-switch fails closed, or that a PVC survives a rebuild. Those are proven only by the L2/L3 Chainsaw behavior and fault-injection tests (conformance/, ADR-0011), which remain mandatory. Admission is a gate, not a guarantee of behavior.

Authored once, shared

kustomization.yaml references the policy files in ../policies/ verbatim — the identical objects the CI kyverno test gate validates — plus the Kyverno install. No policy is forked between CI and admission, with one deliberate exception:

The one deliberate CI vs admission divergence — Secrets

../policies/disallow-plaintext-secrets.yaml (CI) requires a top-level sops block on the Secret manifest. Flux decrypts SOPS before admission, so that block is gone by the time the API server sees the Secret — the CI policy cannot run in-cluster. The admission equivalent is secret-provenance.yaml, which enforces provenance (Secret came from Flux / is an exempt controller Secret) instead of ciphertext. This is escalated in the T-0.5 report because docs/07's literal wording ("reject a plaintext Secret at admission") is not achievable post-decrypt.

Operational note (from ADR-0011)

Admission enforcement adds a failure mode: a bad policy can block legitimate reconciliation. Mitigations: policies ship with their own kyverno test suite (this directory's ../tests), roll out via GitOps, and the webhook failurePolicy: Fail is chosen so the system fails closed (coordination-protocol.md #8) — validate for bootstrap deadlocks in dev/test before prod.