Fix the Security Flaws in a Dockerfile and a Manifest

Original Prepium guide · Written for Kubernetes v1.35 and checked against the official documentation on 6 October 2026. Use a disposable practice cluster. The Dockerfile and manifest below are invented for this guide; review them by reading, no build needed.

Spot the risky line: image and Pod security review

CKS review tasks hand you a Dockerfile or a manifest and ask you to find the line that hurts security. The skill is reading quickly with a checklist: which user the process runs as, which base image you will really get, what ends up inside image layers, and which privileges the Pod spec adds on top. The image and the manifest are linked: if the Pod does not set runAsUser, Kubernetes uses the user from the image metadata, which comes from USER.

Dockerfile USER ──→ image metadata user ──→ container UID (unless securityContext.runAsUser overrides)
FROM tag ──→ may move     FROM tag@digest ──→ fixed      ENV/ARG ──→ stays in image

1. Read a Dockerfile with four questions

FROM node:latest
ENV REGISTRY_TOKEN=tok_live_example
WORKDIR /srv/invoice
COPY . .
RUN npm ci
CMD ["node", "server.js"]

• Which base image? Tags are mutable, so latest or even a version tag can point at different content next month. A digest (image:tag@sha256:...) always resolves to the same image.
• Which user? There is no USER, so the process runs as whatever the base image chose, often root.
• What is baked in? Each ENV creates a layer; unsetting it later does not remove it, and Docker's docs call build args and environment variables inappropriate for secrets.
• How big? A full distro image carries shells, compilers and package managers an attacker can use. Prefer slim or minimal variants, or a multi-stage build that ships only the runtime.

2. The same Dockerfile, reviewed

FROM node:22-alpine@sha256:<digest-you-verified>
WORKDIR /srv/invoice
COPY package*.json ./
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci
COPY . .
USER 10001:10001
CMD ["node", "server.js"]

The secret mount exposes the token only while that one RUN executes, so it never lands in a layer. USER accepts a name or UID with an optional group or GID; set the group explicitly, because a user without a primary group runs with the root group. On the exam, edit only what you are asked to and do not build if the brief says not to.

3. Read the Pod spec with the same eye

    securityContext:
      privileged: true                 # near-root on the host
      allowPrivilegeEscalation: true   # setuid binaries can raise privileges
      runAsUser: 0                     # overrides the image's USER with root

A privileged container is, per the API reference, essentially equivalent to root on the host. allowPrivilegeEscalation controls the no_new_privs flag, and it is always true for a privileged container or one with CAP_SYS_ADMIN, so setting it to false alone does not help while privileged stays true. A hardened version sets runAsNonRoot: true, a non-zero runAsUser, allowPrivilegeEscalation: false and drops all capabilities.

4. Let the cluster grade your manifest

kubectl create namespace prepium-tutorial
kubectl label namespace prepium-tutorial pod-security.kubernetes.io/warn=restricted
kubectl -n prepium-tutorial apply -f invoice-deployment.yaml

Warn mode is applied to Deployments too, so kubectl prints every Restricted-profile violation (privileged, privilege escalation, running as root) without blocking anything. When a Pod does run, kubectl exec into it and run id to see the real UID.

Common mistakes

• Setting runAsNonRoot: true on an image that runs as UID 0: the kubelet validates the image at runtime and refuses to start the container, so the Pod never reaches Running.
• Replacing latest with another moving tag and calling it pinned.
• Deleting a secret with a later RUN rm: the earlier layer still contains it and docker image history --no-trunc shows how it got there.
• Fixing USER in the Dockerfile but leaving runAsUser: 0 in the manifest: the Pod setting overrides the image, so the process is still root.

Cleanup: kubectl delete namespace prepium-tutorial. References: Docker build best practices, Build secrets, Configure a Security Context, Pod Security Standards. Next, try Pod Security Standards or CKAD security contexts.