Pod vs Container Security

Kubernetes Pod vs Container Security Contexts

For someone new to Kubernetes Security Context, it’s what lets you control which user your containers run as and how they access the file system. Think of it like setting Linux user permissions, but now, inside a Kubernetes cluster.

You can apply it:

Pod level: Affects all containers in the pod.

Container level: Set individually per container and overrides pod level settings.

Pod + Container: Uses pod level defaults unless a container explicitly overrides them.

Let’s walk through the three types using real world situations.

1. Pod level Security Context

spec:

securityContext:

runAsUser: 3000

fsGroup: 4000

This setting is inherited by all containers unless overridden at container level. Useful when all containers share the same user or group ID context.

Don’t assume it applies everywhere. If a container explicitly defines its own runAsUser, it will take precedence.

Use case: A log processor pod where both Fluentd and a custom metrics container access shared volumes, and you want them to operate under the same user and file group.

2. Container level Security Context

containers:

- name: app-container

securityContext:

runAsUser: 3000

- name: log-container

securityContext:

runAsUser: 5000

Each container has its own runAsUser. This is precise and flexible and ideal when containers need different privileges.

Note: Container level security context does not use any pod level runAsUser. Define all required security fields explicitly per container if you skip pod level.

Use case: A main Redis app container and a sidecar logging container, they serve different functions, so they should run under different OS users for audit and isolation.

3. Pod + Container – With Override

spec:

securityContext:

runAsUser: 3000

containers:

- name: app-container

securityContext:

runAsUser: 5000

Here, app-container overrides the pod level value. Only containers without their own setting will fall back to the pod-level configuration.

In mixed setups, audit security context at container level first. What’s defined there always wins.

Use case: You set a default runAsUser for consistency, but need a specific container to run as root (e.g., an init container performing privileged setup).

My 2 cents:

Use Pod level when all containers share the same identity.

Use Container level for fine grained privilege control.

Container level always overrides Pod level (know what takes effect).

No one is immune to OOM, throttling alerts and k8s clusters downtime.