Skip to main content

Documentation Index

Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt

Use this file to discover all available pages before exploring further.

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: 
# Local shell
whoami
# Confirm pod is running
kubectl get pod
# NAME             READY   STATUS    RESTARTS   AGE
# Inside the container
kubectl exec ubuntu-sleeper -- whoami
# → root
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: 
    kubectl get pod ubuntu-sleeper -o yaml > ubuntu-sleeper.yaml
  2. In ubuntu-sleeper.yaml, add a container-level securityContext: 
    spec:
  containers:
    - name: ubuntu
      image: ubuntu
      command: ["sleep", "4800"]
      securityContext:
        runAsUser: 1010
      # ...other fields...
  3. Delete and recreate the Pod: 
    kubectl delete pod ubuntu-sleeper --force
kubectl apply -f ubuntu-sleeper.yaml
  4. Verify inside the container: 
    kubectl exec ubuntu-sleeper -- whoami
# → 1010
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?

apiVersion: v1
kind: Pod
metadata:
  name: multi-pod
spec:
  securityContext:
    runAsUser: 1001      # pod-level default
  containers:
    - name: web
      image: ubuntu
      command: ["sleep", "5000"]
      securityContext:
        runAsUser: 1002  # container override
    - name: sidecar
      image: ubuntu
      command: ["sleep", "5000"]
      # no override → inherits pod-level
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:
ContainerrunAsUser
web1002
sidecar1001
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: 
    spec:
  containers:
    - name: ubuntu
      image: ubuntu
      command: ["sleep", "4800"]
      securityContext:
        capabilities:
          add:
            - SYS_TIME
  3. Apply the changes: 
    kubectl delete pod ubuntu-sleeper --force
kubectl apply -f ubuntu-sleeper.yaml
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: 
spec:
  containers:
    - name: ubuntu
      image: ubuntu
      command: ["sleep", "4800"]
      securityContext:
        capabilities:
          add:
            - SYS_TIME
            - NET_ADMIN
Reapply the manifest: 
kubectl delete pod ubuntu-sleeper --force
kubectl apply -f ubuntu-sleeper.yaml
Result: The pod now has both SYS_TIME and NET_ADMIN capabilities.

​
References

Watch Video