Security & Compliance (Audit → Enforce)
Take a cluster from 'policies exist' to 'policies bite'. Kyverno ships four Pod Security and best-practice ClusterPolicies in Audit mode, so nothing is blocked and every violation lands in a policy report. Your job is the part a real team owns: read the report, remediate the workload at the source, promote the policies to Enforce, prove the admission webhook now rejects a non-compliant Pod, and issue a real TLS certificate from the lab CA with cert-manager - on a namespace that is default-deny in both directions.
What you'll do
- Read Kyverno policy reports and identify exactly which rule each workload violates
- Remediate the go-api Deployment at the source so it satisfies all four policies - fix the workload, never the policy
- Triage the violation you cannot fix: exempt the vendor workload with a label-scoped Kyverno PolicyException instead of widening the policy
- Promote a policy from Audit to Enforce with 'kubectl patch', the change that turns a report into a rejection
- Prove enforcement is real: 'kubectl apply --dry-run=server' a root Pod and watch the admission webhook refuse it
- Issue a TLS certificate for go-api from the lab CA, wire it onto the Ingress, and prove the lab-signed leaf is what answers the TLS handshake
- Prove the go-api namespace is really default-deny, get refused from a pod outside it, and read why the ingress and Prometheus allow rules cannot be proven the same way on k3d
Stages
- 1policy-engine
Install the admission controller (Kyverno) and the certificate authority (cert-manager)
kyvernocert-manager - 2baseline-policies
Four ClusterPolicies in Audit mode, and the lab CA chain that signs workload certificates
kyverno-policiescert-issuers - 3namespace-isolation
Lock the go-api namespace to default-deny, re-open only what the workload needs, and add the vendor workload that cannot comply
network-policieslegacy-workloadworkload-baseline - 4observability
The security dashboard that plots violations, certificates and admission latency
security-dashboards
Prerequisites
--deploy-prereqs installs these into the lab for you. They are listed so you know what the scenario depends on.
Related scenarios
- Secrets Management & RotationA workload mounts a Vault-backed secret that External Secrets keeps in sync. You rotate the value in Vault; it must reach the running pod through ESO and the kubelet with no restart and no redeploy. The grade is what the running container reads from disk.
- Autoscaling Under LoadWatch KEDA scale go-api on Prometheus RPS: a spike drives it from 1 to several replicas, then cooldown brings it back. The flagship 'autoscaling actually works' demo, verified under traffic from the load generator.
- Chaos EngineeringRun the chaos engineering loop against go-api with Chaos Mesh: establish a steady state under load, form a hypothesis, inject a failure (pod kill, network delay, CPU and memory stress) and measure the blast radius on a Grafana dashboard. go-api ships as a single replica behind a PodDisruptionBudget, so it starts out with disruptionsAllowed=0: a node drain would block forever while a pod kill is still a full outage. Your job is to find that with an experiment and fix it, then prove the same experiment no longer hurts.