Skip to main content
This guide walks through common securityContext configurations in Kubernetes pods and containers, demonstrating how to control process ownership and Linux capabilities. You’ll see how to:
  • Determine the user that runs a process inside a container
  • Override container user IDs with runAsUser
  • Grant specific capabilities (e.g., SYS_TIME, NET_ADMIN)
For more details, refer to the Kubernetes Pod Security Context documentation.

1. Which user executes the sleep process in the Ubuntu Sleeper pod?

Run whoami locally and inside the container:
Answer: The sleep process runs as root by default.

2. Edit the Ubuntu Sleeper pod to run the process as UID 1010

  1. Export the existing Pod manifest:
  2. In ubuntu-sleeper.yaml, add a container-level securityContext:
  3. Delete and recreate the Pod:
  4. Verify inside the container:
Using --force deletes the Pod immediately. In production clusters, prefer a graceful rollout (e.g., updating a Deployment).
Result: The sleep process now runs as UID 1010.

3. Which user starts processes in the web container of multi-pod.yaml?

Container-level settings override pod-level defaults. Answer: The web container runs as 1002.

4. Which user starts processes in the sidecar container?

Since the sidecar container has no runAsUser block, it inherits from the Pod: Answer: The sidecar container runs as 1001.

5. Update Ubuntu Sleeper to run as root and add the SYS_TIME capability

  1. Remove any runAsUser lines in ubuntu-sleeper.yaml.
  2. Under the container’s securityContext, add the SYS_TIME capability:
  3. Apply the changes:
Granting SYS_TIME allows processes to modify the system clock. Only use this capability if absolutely necessary.
Result: The pod runs as root with the SYS_TIME capability.

6. Add the NET_ADMIN capability to the Ubuntu Sleeper pod

Extend the same securityContext to include both capabilities:
Reapply the manifest:
Result: The pod now has both SYS_TIME and NET_ADMIN capabilities.

References

Watch Video