Context: Cluster: prod Master node: master1 Worker node: worker1 You can switch the cluster/configuration context using the following command: [desk@cli] $ kubectl config use-context prod Task…

This CKS (Certified Kubernetes Security Specialist) task tests your ability to identify and remediate security anti-patterns in both a Dockerfile and a Kubernetes deployment manifest - two of the most critical hardening surfaces in a container workload.

Submitted by zhang_li· May 4, 2026Minimize Microservice Vulnerabilities

Question

Context:
Cluster: prod
Master node: master1
Worker node: worker1
You can switch the cluster/configuration context using the following command:
[desk@cli] $ kubectl config use-context prod
Task:
Analyse and edit the given Dockerfile (based on the ubuntu:18:04 image)
/home/cert_masters/Dockerfile fixing two instructions present in the file being prominent
security/best-practice issues.
Analyse and edit the given manifest file
/home/cert_masters/mydeployment.yaml fixing two fields present in the file being prominent
security/best-practice issues.

Explanation

Approach. For the Dockerfile (ubuntu:18.04 base): the two most prominent issues are (1) running as root - fix by adding a dedicated non-root user and switching to it with 'RUN useradd -r appuser && USER appuser', and (2) using ADD instead of COPY for local files - ADD can fetch remote URLs and auto-extract archives, creating supply-chain risk; replace with COPY for any local file transfer. For /home/cert_masters/mydeployment.yaml: the two most prominent issues are (1) 'privileged: true' in the container's securityContext - this grants the container near-root host access and must be set to 'false', and (2) 'allowPrivilegeEscalation: true' - this allows a process inside the container to gain more privileges than its parent (e.g., via setuid binaries) and must be set to 'false'. Both files should be edited in-place and saved; no other kubectl apply step is needed unless the task explicitly asks for it.

Concept tested. Container and pod security hardening: principle of least privilege applied to both the image build layer (Dockerfile USER directive, safe COPY vs ADD) and the Kubernetes runtime layer (securityContext fields: privileged, allowPrivilegeEscalation, runAsNonRoot). This maps directly to the CKS domain 'Minimize Microservice Vulnerabilities' and the 'System Hardening' domain.

Reference. Kubernetes docs - Configure a Security Context: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ | Docker best practices - USER & COPY: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

Topics

#Dockerfile Security#Kubernetes Security#Container Hardening#Pod Security Standards

Community Discussion

No community discussion yet for this question.

Full CKS Practice