# Security test workloads

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:

```bash
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.