Guardrails That Stop It

• Policy-as-Code: All admission rules are managed in Git and reconciled via Flux.
• Fail-Closed Baseline: Critical security policies are set to Enforce by default in Production.
• Audit-First Rollout: New policies always start in Audit mode to prevent accidental downtime.
• Explicit Exceptions: Policy bypasses require a documented, time-bound label or annotation.

Kyverno vs. Gatekeeper

In this course, we use Kyverno as our policy engine because it is:

• Kubernetes Native: Policies are written in YAML, not a specialized language like Rego.
• Mutation Capable: It can automatically inject sidecars or fix small label errors.
• Image Aware: Built-in support for verifying signatures and attestations (Chapter 15).

Rollout Strategy

1. Develop Audit: Apply the policy in Audit mode in the develop namespace.
2. Evidence Collection: Review PolicyReports to identify existing violations.
3. Upstream Fix: Correct the manifests in Git to comply with the new rules.
4. Production Enforce: Move the policy to Enforce mode once all environments are clean.

Safe Workflow (Step-by-Step)

1. Define Policy: Create a Kyverno ClusterPolicy manifest in YAML.
2. Local Validate: Test the policy against your manifests using the Kyverno CLI.
3. Deploy Audit: Use Flux to deploy the policy in validationFailureAction: Audit.
4. Monitor Reports: Use kubectl get polr to check for violations.
5. Enforce: Change the action to Enforce and verify that non-compliant requests are blocked.

This builds on: Supply chain verification (Chapter 15) — Kyverno enforces what supply chain verified. This enables: Rollback and migrations (Chapter 17) — policies guard schema changes too.