1.5 KiB
1.5 KiB
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. |
| Supplemental | disallow-default-namespace |
Common application resources in default are rejected. |
Namespace hygiene is defense in depth, not a one-to-one 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.