Reject a privileged workload before deployment

A deployment review checks only the first container. A privileged init container slips through. Repair a deliberately small admission predicate and test all container lists.

Requires Node.js 22 or newer. No package installation or server needed. To work in a container instead, open the folder with VS Code Dev Containers or GitHub Codespaces: .devcontainer/devcontainer.json uses the Dev Containers Node.js 24 image, pinned by digest.
1. Unzip all files into one folder.
2. In that folder, run: node --test exercise.test.mjs
3. Edit pod-policy.mjs, then run the same command again.

The starter deliberately fails some tests. A successful repair passes every case, including cases that catch common wrong fixes. The browser runs this same cases.mjs with the same fixtures; locally Node runs your code directly. If you completed the optional first stage in the browser, Download my work adds your input as stage1-input.json and the tests include it. Only run code you wrote or reviewed.

1. Inspect the bypass
Run the init-container case. Reading only containers[0] ignores code that runs before the application.

2. Check pod scope
Reject host namespace sharing and a missing or empty containers list. Do not let a policy exemption in annotations bypass these checks.

3. Check every container
Combine containers, initContainers and ephemeralContainers. For runAsNonRoot use the container’s own value when it sets one and the Pod-level value otherwise; require the effective value to be true. The other settings have no Pod-level default, so a missing value does not satisfy them.

4. Prove legitimate deployment
The ordinary, sidecar and Pod-level fixtures must pass: the Pod-level one is the shape of the guide’s own Deployment. Explain which additional controls you would check in a real restricted workload policy.

SUPPLIED CONTRACT
allowPod(pod) receives a normalized Pod object with spec.containers, optional initContainers and ephemeralContainers, and an optional Pod-level spec.securityContext. The policy rejects hostNetwork, hostPID and hostIPC and requires at least one application container. Every container must run as non-root, as the Pod Security Standards Restricted profile defines it: a container’s own securityContext.runAsNonRoot wins; when the container leaves it unset, the Pod-level spec.securityContext.runAsNonRoot applies; the effective value must be true, and a Pod-level runAsNonRoot:false is rejected outright. allowPrivilegeEscalation, privileged and capabilities have no Pod-level field, so each container must set allowPrivilegeEscalation:false, must not set privileged:true, and must list ALL in capabilities.drop.

REFERENCE
reference.mjs contains an explained solution: The safe app and safe sidecar pass because every listed container meets the policy. The Pod-level fixture, the guide’s Deployment shape, passes because each container leaves runAsNonRoot unset and inherits true from spec.securityContext, while setting allowPrivilegeEscalation:false and dropping ALL itself. A container that sets runAsNonRoot:false fails even under a Pod-level true, because the container value overrides it, and a Pod-level false fails outright. A privileged init or ephemeral container fails even when the main app is safe. hostNetwork fails at Pod scope. Missing securityContext, allowPrivilegeEscalation=true or dropping only NET_RAW fails the container predicate. An empty application-container list is rejected before every(), preventing an empty-list truth from authorizing a malformed workload.

SCOPE
This is a small policy model for normalized fixtures, not a complete implementation of the Pod Security Standards. The Restricted profile also requires a RuntimeDefault or Localhost seccomp profile (which, like runAsNonRoot, may be set at Pod level), allows adding back only NET_BIND_SERVICE, and restricts volume types, runAsUser 0 and OS-specific fields; real admission also handles exemptions, API versions and controller-generated Pods. Verify enforcement with Pod Security Admission in a disposable cluster.

NEXT TASK
Which admission mechanism evaluates generated Pods and ephemeral-container updates in your cluster?

SOURCE
https://kubernetes.io/docs/concepts/security/pod-security-standards/
