> ## 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.

# Lab Solution Security Contexts

> Practical Kubernetes securityContext guide showing commands and YAML to set container UIDs and Linux capabilities, with validation steps and troubleshooting tips.

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):

```bash theme={null}
kubectl exec ubuntu-sleeper -- whoami
```

Example output:

```text theme={null}
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:

1. Export the current Pod manifest to a file:

```bash theme={null}
kubectl get pod ubuntu-sleeper -o yaml > ubuntu-sleeper.yaml
```

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

```yaml theme={null}
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
```

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

<Callout icon="warning" color="#FF6B6B">
  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.
</Callout>

```bash theme={null}
kubectl delete pod ubuntu-sleeper --force --grace-period=0
kubectl apply -f ubuntu-sleeper.yaml
```

4. Validate the UID inside the recreated Pod:

```bash theme={null}
kubectl exec ubuntu-sleeper -- id -u
```

Expected output:

```text theme={null}
1010
```

***

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

Consider this `multi-pod` manifest excerpt:

```yaml theme={null}
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:

```yaml theme={null}
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:

```bash theme={null}
kubectl delete pod ubuntu-sleeper --force --grace-period=0
kubectl apply -f ubuntu-sleeper.yaml
```

Validate Pod recreation:

```bash theme={null}
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:

```yaml theme={null}
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:

```bash theme={null}
kubectl delete pod ubuntu-sleeper --force --grace-period=0
kubectl apply -f ubuntu-sleeper.yaml
```

Confirm Pod is created:

```bash theme={null}
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.

<Callout icon="lightbulb" color="#1CB2FE">
  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.
</Callout>

***

## Links and references

* [Kubernetes securityContext docs](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
* [Kubernetes API - PodSpec securityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#podsecuritycontext-v1-core)
* [Capabilities(7) — Linux manual page](https://man7.org/linux/man-pages/man7/capabilities.7.html)

<CardGroup>
  <Card title="Watch Video" icon="video" cta="Learn more" href="https://learn.kodekloud.com/user/courses/cka-certification-course-certified-kubernetes-administrator/module/77826599-d456-4cb5-8cbc-b713cc077b45/lesson/7c215ca1-7d31-493a-b3d0-ef4fe39db467" />
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.