Challenge
DifficultyHard
Community stats No attempts yet

Edit a File in a Running Kubernetes Pod: a Distroless Container Case

Learn how to edit a file in a distroless container that runs as a non-root user in a Kubernetes namespace that enforces the baseline Pod Security Standard.

The Pod web-server in the default namespace runs the same web server as in the Non-Root Container Case of this challenge, but this time from a distroless image. The image has no shell, no tar, and no other tools, and the server runs as a non-root user that owns the files in the /var/www/html directory. On top of that, the default namespace enforces the baseline level of the Pod Security Standards.

Your task is to edit the /var/www/html/index.html file in this container without restarting the app container or recreating the Pod:

  • Replace the phrase "Hello World" with the phrase "Hello Labs".
  • Add the phrase "Practice for the win!" anywhere in the file.

You can change resources only in the default namespace. You may change the Pod as long as the app container keeps running. To see the current page, forward a local port to the Pod with kubectl port-forward and send a request to it:

kubectl port-forward pod/web-server 8080:8080 &

curl localhost:8080
Hint 1

Without a shell and tar in the container, kubectl exec and kubectl cp can't help. An ephemeral debug container brings its own tools. If you haven't solved the Non-Root Container Case yet, start there.

Hint 2

The API server rejects your debug container? The baseline Pod Security level forbids privileged containers and extra capabilities, such as the SYS_PTRACE capability that the default general profile of kubectl debug adds. Look for a kubectl debug --profile value that complies with baseline.

Hint 3

A baseline-compliant debug container that runs as root can see the web server process, but reading /proc/<PID>/root of that process fails with Permission denied. Without the SYS_PTRACE capability, the kernel allows access to /proc/<PID>/root only to processes with the same user and group IDs as the target process.

Hint 4

Which user and group does the web server run as? The ps command in the debug container shows the user, and the /proc/<PID>/status file shows both the user (Uid:) and the group (Gid:) IDs.

Hint 5

The --custom flag of kubectl debug takes a partial container spec from a JSON or YAML file. Such a spec can set the securityContext of the debug container, including the user it runs as.