Question: 6 SIMULATION Analyze and edit the given Dockerfile FROM ubuntu:latest RUN apt-get update -y RUN apt-get install nginx -y COPY entrypoint.sh / ENTRYPOINT ["/entrypoint.sh"] USER ROOT Fixing…

This simulation tests knowledge of container security hardening - specifically fixing insecure Dockerfile instructions and completing a Kubernetes Pod securityContext to enforce least-privilege principles.

Submitted by tarun92· May 5, 2026Minimize Microservice Vulnerabilities

Question

Question: 6
SIMULATION
Analyze and edit the given Dockerfile
FROM ubuntu:latest
RUN apt-get update -y
RUN apt-get install nginx -y
COPY entrypoint.sh /
ENTRYPOINT ["/entrypoint.sh"]
USER ROOT
Fixing two instructions present in the file being prominent security best practice issues
Analyze and edit the deployment manifest file
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-2
spec:
securityContext:

Explanation

Approach. For the Dockerfile, two security issues must be fixed: (1) Replace 'FROM ubuntu:latest' with a pinned version like 'FROM ubuntu:22.04' - using 'latest' is unpredictable and may silently pull unvetted or vulnerable image layers; (2) Replace 'USER ROOT' with a non-root user such as 'USER nginx' or 'USER nobody', and move the USER instruction BEFORE ENTRYPOINT - running containers as root violates least-privilege and expands the blast radius of any compromise. For the Kubernetes Pod manifest, the incomplete 'securityContext:' block should be populated with fields such as 'runAsNonRoot: true', 'runAsUser: 1000', 'fsGroup: 2000', and at the container level: 'allowPrivilegeEscalation: false', 'readOnlyRootFilesystem: true', and 'capabilities: drop: ["ALL"]' - these enforce that workloads cannot escalate privileges or write to the root filesystem.

Concept tested. Container and Kubernetes security hardening: pinning base image versions to avoid supply-chain drift, enforcing non-root execution in Dockerfiles via the USER directive (placed correctly before ENTRYPOINT), and configuring Pod/container-level securityContext in Kubernetes to implement least-privilege, prevent privilege escalation, and restrict filesystem access.

Reference. CKS (Certified Kubernetes Security Specialist) - Domain: Minimize Microservice Vulnerabilities; Docker Best Practices: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/; Kubernetes securityContext: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

Topics

#Dockerfile Security#Kubernetes Pod SecurityContext#Non-Root User#Least Privilege

Community Discussion

No community discussion yet for this question.

Full CKS Practice