Kubernetes Pod Security Configuration

Kubernetes Pod Security Configuration is the set of fields within spec.securityContext, at both the Pod level and the individual container level, that constrain what a container's process is permitted to do at the kernel level — what user it runs as, what Linux capabilities it holds, whether it can escalate privileges, and what mandatory access control profile confines it — forming the primary in-manifest mechanism for reducing a workload's attack surface beyond whatever the container image itself was built with.

User and Group Identity

runAsUser, runAsGroup, and runAsNonRoot

runAsUser and runAsGroup explicitly set the numeric UID and GID a container's process runs as, overriding whatever the image's own Dockerfile specified, while runAsNonRoot, when set to true, causes the kubelet to refuse to start the container at all if the resolved user would be UID 0, providing a declarative guardrail against accidentally running as root even if an image was built (or later modified) to default to it.

fsGroup for Volume Ownership

fsGroup, set at the Pod level, causes volumes supporting ownership management to have their group ownership set to the specified GID when mounted, ensuring a non-root process can still read and write files within a mounted volume without requiring the volume's contents to already be owned by that exact user.

Linux Capabilities

Dropping Capabilities by Default

A container's capabilities.drop list removes specific Linux capabilities from the default set the container would otherwise receive, with a common hardening practice dropping ALL capabilities and then explicitly adding back only the small number a given workload genuinely requires through capabilities.add, rather than retaining the broad default capability set an unprivileged container process would otherwise carry.

Why Capability Minimization Matters

Because many container escape and privilege escalation techniques rely on specific capabilities being present, minimizing a container's capability set directly shrinks the set of kernel-level actions available to an attacker who compromises the process running inside it, independent of whatever application-level vulnerabilities might have provided initial access.

Privilege Escalation Controls

allowPrivilegeEscalation

Setting allowPrivilegeEscalation: false prevents a container's process from gaining more privileges than its parent process had, blocking mechanisms such as setuid binaries from being used to escalate privileges within the container even if such a binary happened to be present in the image.

privileged Mode

The privileged field, when true, effectively disables most container isolation, giving the container access to all host devices and capabilities roughly equivalent to processes running directly on the host; this setting is reserved for a narrow set of infrastructure workloads genuinely requiring that level of host access and is generally disallowed for ordinary application workloads under any reasonable security posture.

Filesystem Restrictions

readOnlyRootFilesystem

Setting readOnlyRootFilesystem: true mounts the container's root filesystem as read-only, preventing a compromised process from writing to or modifying files within the image's own filesystem layer, forcing any legitimate need for writable storage to go through explicitly declared, more tightly scoped volumes instead.

Mandatory Access Control Profiles

seccomp Profiles

seccompProfile restricts which system calls a container's process may invoke, with a RuntimeDefault type applying the container runtime's own baseline restricted syscall set, and a Localhost type referencing a custom, more specifically tailored profile stored on the node, narrowing the kernel attack surface available to the process well beyond what capability restrictions alone address.

SELinux and AppArmor Options

seLinuxOptions and, through a Pod-level annotation or, in newer configurations, a dedicated field, AppArmor profile selection apply the host's mandatory access control system to the container, adding a further, independently enforced layer of confinement that operates beneath and alongside the container runtime's own namespace and capability-based isolation.

Layering From Pod Defaults to Container Overrides

Pod-Level Defaults, Container-Level Precision

Security context fields set at the Pod level establish a baseline applied to every container unless a specific container's own securityContext overrides that particular field, letting an author set sensible, restrictive Pod-wide defaults while still allowing an individual container with a genuinely different requirement (such as needing a specific capability the others do not) to diverge precisely where necessary rather than loosening the Pod-wide default for every container.