1.22 Kubernetes Security Context Definition
Kubernetes Security Context Definition sets security boundaries for containers, defining user, group, and privilege settings.
Kubernetes Security Context Definition is the precise characterization of the security context as a set of privilege and access-control settings attached at the Pod or container level, defined to constrain how a container's process interacts with the underlying operating system, distinct from RBAC and NetworkPolicy in that it governs behavior within a single running container rather than access to the API or the network.
Security Context Defined by Scope
Pod-Level vs. Container-Level Settings
A security context can be defined at the Pod level, applying defaults across every container within it, or at the individual container level, overriding those defaults for that specific container; this layered definition allows shared baseline settings alongside per-container exceptions where justified.
Governs the Process, Not the API
Unlike RBAC, which is defined around what an identity may do through the Kubernetes API, a security context is defined around what a container's own operating system process is permitted to do once it is already running, making it a fundamentally different layer of control.
Identity and Privilege Settings
Run-As User and Group
A security context is defined to include the ability to specify which user and group ID a container's process should run as, allowing a container to be constrained to run as a non-root user regardless of what user is defined in the underlying container image.
Privilege Escalation Controls
The definition includes a setting controlling whether a process is allowed to gain more privileges than its parent process, a control specifically aimed at closing off a class of techniques that would otherwise let a constrained container regain elevated privileges at runtime.
Filesystem and Capability Settings
Read-Only Root Filesystem
A security context is defined to support marking a container's root filesystem as read-only, meaning any writes the application attempts outside explicitly mounted writable volumes will fail, reducing the avenues available for a compromised process to persist changes.
Linux Capabilities
Rather than the coarse choice between fully privileged and fully unprivileged, the security context definition allows individual Linux capabilities to be added or dropped, enabling a container to be granted only the narrow, specific kernel privileges it actually requires.
Privileged Mode as an Extreme Case
Disabling Isolation Entirely
At the far end of the security context definition is privileged mode, which, when enabled, effectively disables most of the isolation Kubernetes and the container runtime would otherwise provide, granting the container capabilities roughly equivalent to direct access to the host.
What Security Context Does Not Cover
Not Network or API Access Control
A security context definition is scoped entirely to process-level privilege on a single host; it makes no statement about which other Pods a container may communicate with over the network or which API resources its associated service account may access, both of which are governed by separate, independently defined mechanisms.