The two manifests in the Kustomization are intentionally allowed through Kyverno. ArgoCD manages them so the baseline always has one admission-pass workload and one runtime-alert workload.

The manifests under blocked/ are negative tests. They are intentionally not included in the Kustomization because ArgoCD would continuously report them as failed syncs. Apply them manually and expect admission rejection:

kubectl apply --server-side --dry-run=server -f test-workloads/blocked/privileged-pod.yaml
kubectl apply --server-side --dry-run=server -f test-workloads/blocked/root-container.yaml
kubectl apply --server-side --dry-run=server -f test-workloads/blocked/host-network-pod.yaml
kubectl apply --server-side --dry-run=server -f test-workloads/blocked/unapproved-registry-pod.yaml
kubectl apply --server-side --dry-run=server -f test-workloads/blocked/default-namespace-pod.yaml

Expected policy coverage:

Manifest	Expected result	Policy or detector
`blocked/privileged-pod.yaml`	Rejected	`disallow-privileged`, CIS 5.2.2
`blocked/root-container.yaml`	Rejected	`require-non-root`, CIS 5.2.7
`blocked/host-network-pod.yaml`	Rejected	`disallow-host-network`, CIS 5.2.3 and 5.2.5
`blocked/unapproved-registry-pod.yaml`	Rejected	`restrict-image-registries`, supplemental supply-chain control
`blocked/default-namespace-pod.yaml`	Rejected	`disallow-default-namespace`, supplemental namespace control
`compliant-workload.yaml`	Accepted	Admission baseline
`suspicious-shell.yaml`	Accepted, then alerted	Falco shell detection

The suspicious workload is intentionally compliant at admission. Its shell process is the runtime event that Falco should report.