> ## 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.
# Isolation and Segmentation Security Context
> This lesson covers Kubernetes security contexts for controlling permissions and access for Pods and containers, including best practices and configuration levels.
Welcome to this lesson on **Security Contexts in Kubernetes**. Security contexts allow you to control permissions and access for Pods and containers. You will learn:
* How to mirror Docker security options in Kubernetes
* The difference between Pod-level and Container-level configurations
* Best practices for applying user IDs and Linux capabilities
For detailed reference, see the [Kubernetes Security Context Documentation](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/).
***
## Why Security Contexts Matter
Security contexts help you enforce least-privilege container execution:
* Define which Linux user or group a container runs as
* Grant or restrict Linux capabilities (e.g., `NET_ADMIN`, `SYS_TIME`)
* Enable Pod-level settings that apply to all containers
If you’ve used Docker, you may be familiar with:
```bash theme={null}
# Run container as a specific user
docker run --user=1001 ubuntu sleep 3600
# Grant a Linux capability
docker run --cap-add MAC_ADMIN ubuntu
```
Kubernetes adopts the same principles, but you configure them in your Pod spec.
***
## Security Context Levels
Kubernetes lets you apply security contexts at two scopes:
| Level | Applies To | Common Settings |
| --------------- | ----------------------- | ------------------------------------------------------- |
| Pod-level | All containers in a Pod | `runAsUser`, `runAsGroup`, `fsGroup` |
| Container-level | A single container | `runAsUser`, `runAsGroup`, `capabilities`, `privileged` |
***
## Pod-Level Security Context
A Pod-level security context propagates settings to every container within that Pod. This is ideal for defining a consistent user and group ID across all containers.
```yaml theme={null}
apiVersion: v1
kind: Pod
metadata:
name: web-pod
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
containers:
- name: ubuntu
image: ubuntu
command: ["sleep", "3600"]
```
You cannot set Linux capabilities (`capabilities.add`) at the Pod level. To grant capabilities, use a container-level security context.
***
## Container-Level Security Context
When you need fine-grained control—such as adding or dropping specific Linux capabilities—apply the security context directly to the container:
```yaml theme={null}
apiVersion: v1
kind: Pod
metadata:
name: web-pod
spec:
containers:
- name: ubuntu
image: ubuntu
command: ["sleep", "3600"]
securityContext:
runAsUser: 1000
runAsGroup: 3000
capabilities:
add: ["MAC_ADMIN", "NET_RAW"]
drop: ["ALL"]
privileged: false
```
Running containers in `privileged` mode grants all Linux capabilities and should be avoided unless absolutely necessary.
***
## Best Practices
* Always run containers as non-root users (`runAsUser` ≥ 1000).
* Use Pod-level context for uniform settings; override at the container level only when needed.
* Drop unnecessary capabilities (`capabilities.drop: ["ALL"]`) and add only those required.
***
## Further Reading
* [Kubernetes Pods Security Context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
* [Docker Run Reference](https://docs.docker.com/engine/reference/run/)
* [Understanding Linux Capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html)
Keep practicing with these configurations to strengthen your cluster’s security. See you in the next lesson!