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…

Question

Explanation

This question tests your ability to identify and remediate the two most prominent security/best-practice violations commonly embedded in a Dockerfile and a Kubernetes Deployment manifest, a core skill for the CKS (Certified Kubernetes Security Specialist) exam.

Approach. For the Dockerfile, the two canonical issues are: (1) using the 'latest' image tag (e.g., 'FROM ubuntu:latest') instead of a pinned, immutable version like 'FROM ubuntu:22.04' - unpinned tags introduce supply-chain risk; and (2) running as root by default (no USER directive or an explicit 'USER root') - fix by adding a non-root USER instruction such as 'USER 65534' or a named non-root user. For the Deployment manifest (/home/cert_masters/mydeployment.yaml), the two canonical issues are: (1) 'privileged: true' in the container's securityContext - this grants the container near-host-level capabilities and must be set to 'privileged: false'; and (2) 'allowPrivilegeEscalation: true' - this allows a process to gain more privileges than its parent and must be set to 'allowPrivilegeEscalation: false'. Applying all four fixes removes the most prominent attack surface exposed by the default/misconfigured resources.

Concept tested. Container and Kubernetes workload hardening: image pinning, non-root container execution, disabling privileged mode, and preventing privilege escalation - all core topics in the CKS 'Minimize Microservice Vulnerabilities' and 'Supply Chain Security' domains.

Reference. CKS Exam Curriculum - 'Minimize Microservice Vulnerabilities' and 'Supply Chain Security'; Kubernetes docs: Pod Security Context (securityContext.privileged, allowPrivilegeEscalation); Dockerfile best practices (docs.docker.com/develop/develop-images/dockerfile_best-practices)

No community discussion yet for this question.