Lab Solution Security Contexts

This guide walks through practical Kubernetes securityContext examples. For each task you’ll find the commands and YAML edits used to complete it, plus validation steps. Use these patterns to manage process UIDs and Linux capabilities for containers in a cluster. Prerequisites:

kubectl configured to the target cluster
A running ubuntu-sleeper Pod (or the ability to create/replace it)
Basic familiarity with editing YAML files

1) Which user executes the sleep process in the `ubuntu-sleeper` Pod?

To determine the user a process runs as inside a container, exec into the Pod and run whoami (or id -u for numeric UID):

kubectl exec ubuntu-sleeper -- whoami

Example output:

root

Answer: root

2) Edit the `ubuntu-sleeper` Pod to run the sleep process with UID 1010

Goal: change the Pod so the container processes run as UID 1010. We’ll add a pod-level securityContext.runAsUser to the manifest and recreate the Pod. Steps:

Export the current Pod manifest to a file:

kubectl get pod ubuntu-sleeper -o yaml > ubuntu-sleeper.yaml

Edit ubuntu-sleeper.yaml and add the pod-level securityContext under spec::

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-sleeper
spec:
  securityContext:
    runAsUser: 1010
  containers:
  - name: ubuntu
    image: ubuntu
    command: ["sleep", "4800"]
    imagePullPolicy: Always
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-wvn5z
      readOnly: true
  restartPolicy: Always

Replace the running Pod. This example deletes the Pod immediately then applies the edited manifest:

Immediate deletion with --force does not wait for the container to terminate cleanly; the process may continue running on the node for a short time. Use with care.

kubectl delete pod ubuntu-sleeper --force --grace-period=0
kubectl apply -f ubuntu-sleeper.yaml

Validate the UID inside the recreated Pod:

kubectl exec ubuntu-sleeper -- id -u

Expected output:

3) Given `multi-pod.yaml`, with what user are processes in the `web` container started?

Consider this multi-pod manifest excerpt:

apiVersion: v1
kind: Pod
metadata:
  name: multi-pod
spec:
  securityContext:
    runAsUser: 1001
  containers:
  - image: ubuntu
    name: web
    command: ["sleep", "5000"]
    securityContext:
      runAsUser: 1002

  - image: ubuntu
    name: sidecar
    command: ["sleep", "5000"]

The Pod-level securityContext sets runAsUser: 1001.
The web container defines a container-level securityContext with runAsUser: 1002, which overrides the Pod-level value for that container.

Answer for web container: 1002

4) With what user are processes in the `sidecar` container started?

Since the sidecar container has no container-level securityContext, it inherits the Pod-level runAsUser: 1001. Answer for sidecar container: 1001 Quick reference table:

Container	Effective `runAsUser`
`web`	`1002`
`sidecar`	`1001`

5) Update `ubuntu-sleeper` to run as root and add the `SYS_TIME` capability

Goal: Ensure the container runs as root (default) and grants the SYS_TIME capability. Approach:

Remove any runAsUser (root is default).
Add SYS_TIME to the container securityContext.capabilities.add list.

Edit ubuntu-sleeper.yaml so the container section contains:

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-sleeper
spec:
  containers:
  - name: ubuntu
    image: ubuntu
    command: ["sleep", "4800"]
    imagePullPolicy: Always
    securityContext:
      capabilities:
        add: ["SYS_TIME"]
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-km279
      readOnly: true
  restartPolicy: Always

Apply the change:

kubectl delete pod ubuntu-sleeper --force --grace-period=0
kubectl apply -f ubuntu-sleeper.yaml

Validate Pod recreation:

kubectl get pod ubuntu-sleeper

6) Add the `NET_ADMIN` capability as well

To grant both SYS_TIME and NET_ADMIN, extend the add list:

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-sleeper
spec:
  containers:
  - name: ubuntu
    image: ubuntu
    command: ["sleep", "4800"]
    imagePullPolicy: Always
    securityContext:
      capabilities:
        add: ["SYS_TIME", "NET_ADMIN"]
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-km279
      readOnly: true
  restartPolicy: Always

Apply the update:

kubectl delete pod ubuntu-sleeper --force --grace-period=0
kubectl apply -f ubuntu-sleeper.yaml

Confirm Pod is created:

kubectl get pod ubuntu-sleeper

Inspecting effective capabilities inside the container

The default ubuntu image may not include tools to inspect capabilities. Two common approaches:

Install libcap2-bin inside the ubuntu container and run capsh --print:
1. Exec into the container: kubectl exec -it ubuntu-sleeper -- bash
2. Install tools: apt-get update && apt-get install -y libcap2-bin
3. Run: capsh --print
Run a debug/utility container that already contains capability tools and mount the same namespaces if needed.

If you only need to verify capability granting, consider using a lightweight debug image (for example nicolaka/netshoot) that includes diagnostic utilities. This avoids installing packages inside a running production container.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Lab Solution Security Contexts

1) Which user executes the sleep process in the `ubuntu-sleeper` Pod?

2) Edit the `ubuntu-sleeper` Pod to run the sleep process with UID 1010

3) Given `multi-pod.yaml`, with what user are processes in the `web` container started?

4) With what user are processes in the `sidecar` container started?

5) Update `ubuntu-sleeper` to run as root and add the `SYS_TIME` capability

6) Add the `NET_ADMIN` capability as well

Inspecting effective capabilities inside the container

Links and references

Watch Video

​1) Which user executes the sleep process in the ubuntu-sleeper Pod?

​2) Edit the ubuntu-sleeper Pod to run the sleep process with UID 1010

​3) Given multi-pod.yaml, with what user are processes in the web container started?

​4) With what user are processes in the sidecar container started?

​5) Update ubuntu-sleeper to run as root and add the SYS_TIME capability

​6) Add the NET_ADMIN capability as well

​Inspecting effective capabilities inside the container

​Links and references

Watch Video

1) Which user executes the sleep process in the `ubuntu-sleeper` Pod?

2) Edit the `ubuntu-sleeper` Pod to run the sleep process with UID 1010

3) Given `multi-pod.yaml`, with what user are processes in the `web` container started?

4) With what user are processes in the `sidecar` container started?

5) Update `ubuntu-sleeper` to run as root and add the `SYS_TIME` capability

6) Add the `NET_ADMIN` capability as well

Inspecting effective capabilities inside the container

Links and references