Kubernetes Security Context Definition

Kubernetes Security Context Definition is the precise characterization of securityContext, a field formally definable at both the Pod level and the individual container level, that controls the operating-system-level security attributes under which a Pod's containers actually execute, distinct from RBAC, which governs what API actions an identity may perform. Where RBAC constrains interactions with the Kubernetes API, securityContext constrains what a container's own process is permitted to do once it is already running, at the level of the underlying Linux kernel.

Formal Scope: Pod-Level vs. Container-Level

Two Independent Application Points

A securityContext formally exists at two levels: spec.securityContext, applying settings across every container in the Pod, and spec.containers[].securityContext, applying settings to a single named container, with container-level settings formally overriding the corresponding Pod-level setting where both are specified for the same field.

spec:
  securityContext:
    runAsNonRoot: true
    fsGroup: 2000
  containers:
    - name: api
      securityContext:
        runAsUser: 10001
        readOnlyRootFilesystem: true

Identity-Related Fields

runAsUser and runAsGroup

runAsUser and runAsGroup formally set the numeric user and group ID under which the container's process runs, overriding whatever user is specified in the container image itself, ensuring a known, deliberately chosen identity regardless of image contents.

runAsNonRoot

runAsNonRoot formally instructs the kubelet to reject starting a container whose effective user ID resolves to root (UID 0), acting as a validation gate rather than a mechanism that itself changes the running user.

securityContext:
  runAsNonRoot: true
  runAsUser: 10001

Privilege-Related Fields

privileged

privileged formally grants a container nearly all the capabilities and device access of the host itself, effectively disabling the isolation the container boundary would otherwise provide; it is formally the most permissive setting available and is reserved for cases requiring direct hardware or kernel access.

allowPrivilegeEscalation

allowPrivilegeEscalation formally controls whether a process within the container can gain more privileges than its parent process, such as through a setuid binary; setting it to false formally closes off a specific class of privilege-escalation techniques regardless of the container's other permissions.

securityContext:
  privileged: false
  allowPrivilegeEscalation: false

capabilities

capabilities.add and capabilities.drop formally grant or revoke individual Linux capabilities, fine-grained kernel privileges, independently of the broader privileged setting, allowing a container to hold exactly the specific elevated capability it requires, such as binding to a privileged port, without the sweeping grant that privileged: true represents.

securityContext:
  capabilities:
    drop: ["ALL"]
    add: ["NET_BIND_SERVICE"]

Filesystem-Related Fields

readOnlyRootFilesystem

readOnlyRootFilesystem formally mounts the container's root filesystem as read-only, preventing any process within it from writing outside of explicitly declared writable volumes, constraining the effect of a compromised process attempting to modify the container's own files.

fsGroup

fsGroup, formally set at the Pod level, applies a supplemental group ID to every volume mounted into any container in the Pod, ensuring consistent, predictable file ownership on mounted storage regardless of which specific container or user ID last wrote to it.

spec:
  securityContext:
    fsGroup: 2000
  containers:
    - name: app
      securityContext:
        readOnlyRootFilesystem: true
      volumeMounts:
        - name: tmp
          mountPath: /tmp
  volumes:
    - name: tmp
      emptyDir: {}

Namespace and Profile Fields

Host Namespace Sharing

hostNetwork, hostPID, and hostIPC, formally set at the Pod level rather than within securityContext itself but governing closely related isolation guarantees, control whether the Pod shares the host's network, process ID, or inter-process communication namespace, each formally removing a layer of isolation the Pod would otherwise have from the node it runs on.

seccompProfile

seccompProfile formally restricts the set of system calls a container's processes may invoke, either to a defined custom profile or to RuntimeDefault, the container runtime's own baseline restricted set, narrowing the kernel attack surface available to a compromised process.

securityContext:
  seccompProfile:
    type: RuntimeDefault

Formal Relationship to Pod Security Admission

Enforcement, Not Just Configuration

While securityContext fields are configuration set by the workload author, Pod Security Admission formally enforces that a Pod's declared securityContext values satisfy a chosen baseline (privileged, baseline, or restricted) at the namespace level, rejecting Pods whose settings fall short, turning individually optional fields into a mandatory floor within namespaces where the stricter profiles are applied.

kubectl get pod codartium-app -o jsonpath='{.spec.securityContext}'
kubectl get pod codartium-app -o jsonpath='{.spec.containers[0].securityContext}'