# CIS control to Kyverno mapping

The policy set is scoped to namespaces carrying the
`security-baseline/open: "true"` label. This makes the local demo predictable
and avoids applying workload admission rules to platform namespaces.

| CIS control | Policy | What the demo proves | Boundary |
| --- | --- | --- | --- |
| 5.2.2 | `disallow-privileged` | A Pod with `privileged: true` is rejected. | Does not replace host hardening or Linux capability review. |
| 5.2.3 | `disallow-host-network` | A Pod with `hostPID: true` is rejected. | Does not cover every host namespace or hostPath risk. |
| 5.2.5 | `disallow-host-network` | A Pod with `hostNetwork: true` is rejected. | Does not replace network policy. |
| 5.2.7 | `require-non-root` | A Pod without explicit non-root execution is rejected. | Does not prove the image cannot switch users internally. |
| 5.5.1 | `restrict-image-registries` | Images outside the approved registry set are rejected. | Full provenance needs signing, verification, and trusted build controls. |
| 5.7.3 supplemental | `require-resource-limits` | Pods must declare CPU and memory limits. | Resource limits are a defense-in-depth control, not a direct CIS test. |

The Kubernetes CIS Benchmark is broader than admission policy. kube-bench
covers node, control-plane, RBAC, audit, network policy, and manual review
areas that these Kyverno policies do not implement.