Perform the following fixes: 1. For Dockerfile: Fix the image version & user name in Dockerfile. 2. For mydeployment.yaml: Fix security contexts.

Question

Explanation

Explanation: Dockerfile & Kubernetes Security Hardening

Overall Goal

This question tests your ability to apply container security best practices at two layers: the image build stage (Dockerfile) and the runtime/orchestration stage (mydeployment.yaml). Together, they implement the principle of least privilege - containers should run with only the permissions they absolutely need.

Fix 1: Dockerfile - Image Version

The problem: Using latest as the image tag (e.g., FROM ubuntu:latest) is a security and stability anti-pattern.

The fix: Pin to a specific, known-good version:

# Bad
FROM ubuntu:latest

# Good
FROM ubuntu:20.04

Why it matters:

• latest can silently pull a newer image with breaking changes or unpatched CVEs
• Exams (especially CKS) explicitly require pinned versions for supply chain security
• Reproducible builds require pinned tags

What breaks if skipped: The image is non-deterministic - it can change between builds, introducing unexpected vulnerabilities or behavior.

Fix 2: Dockerfile - User Name

The problem: By default, Dockerfile runs processes as root unless a USER directive is specified.

The fix: Add a non-root user:

# Bad (implicit root)
FROM ubuntu:20.04

# Good
FROM ubuntu:20.04
RUN useradd -r appuser
USER appuser

Or use an existing non-root user like nobody:

USER nobody

Why it matters:

• If an attacker exploits the app, they get root inside the container, making container escape far more dangerous
• CKS and CKAD exams specifically test for this

What breaks if skipped: The container runs as UID 0 (root), violating least privilege and likely failing runAsNonRoot enforcement at the pod level.

Fix 3: mydeployment.yaml - Security Contexts

The problem: Missing or permissive securityContext fields allow privilege escalation and broad filesystem access.

The fix: Apply both pod-level and container-level security contexts:

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: myapp
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL

Key fields and why each matters:

What breaks if skipped:

• Without allowPrivilegeEscalation: false, a process can gain more privileges than its parent - a common exploit vector
• Without dropping capabilities, the container may have network raw access or ability to load kernel modules

Order Matters

Fix the Dockerfile first, then the deployment YAML. The YAML's runAsNonRoot: true enforcement depends on the image being built with a non-root USER. If you fix the YAML but not the Dockerfile, Kubernetes will reject the pod at admission.

Memory Tip

"Pin, Drop, Lock"

• Pin the image version (no latest)
• Drop root user and capabilities
• Lock the filesystem (readOnlyRootFilesystem) and privilege escalation (allowPrivilegeEscalation: false)

This covers both the Dockerfile and security context fixes in one mnemonic.

No community discussion yet for this question.