8.20 Kubernetes Pod Runtime Identity

Kubernetes Pod Runtime Identity is the combination of user, group, and process-level attributes that define how a Pod's containers present themselves to the underlying operating system kernel while they are executing. This identity determines what files a process can read or write, what system resources it can access, and how the kernel enforces permission boundaries around it, distinct from the Kubernetes-level identity used for API server authentication such as service accounts.

User and Group Identifiers

runAsUser

The runAsUser field specifies the numeric user ID that the container's entrypoint process runs as, overriding whatever user is defined in the container image itself. Explicitly setting this value ensures predictable behavior across different images, rather than relying on the arbitrary or default user baked into each image, some of which run as root by default.

runAsGroup

The runAsGroup field specifies the primary group ID under which the container process runs. When not explicitly set, the runtime typically defaults to the group defined in the image or to group zero, which can unintentionally grant broader filesystem access than intended if group-based permissions are in use.

runAsNonRoot

Setting runAsNonRoot: true instructs the kubelet to validate, at container start time, that the resolved user ID is not zero. If the image is configured to run as root and no runAsUser override forces a non-root identity, the container fails to start rather than silently running with root privileges, making this field a strong safeguard against misconfigured images.

Filesystem Ownership and Group Access

fsGroup

The fsGroup field, set at the Pod level, changes the group ownership of mounted volumes to the specified group ID when the volume is attached, and applies the setgid bit so that files subsequently created within the volume inherit that group. This allows containers running as a non-root user to still read and write to shared volumes without requiring broader file permissions.

fsGroupChangePolicy

The fsGroupChangePolicy field controls when ownership changes triggered by fsGroup are applied. The Always setting reapplies ownership on every mount, while OnRootMismatch skips the change if the volume's root already has the correct group ownership, which can significantly reduce Pod startup time for volumes containing large numbers of files.

Supplemental Groups

supplementalGroups

The supplementalGroups field adds additional group IDs to the container process beyond its primary group, without changing the primary group identity itself. This is useful when a process needs simultaneous membership in multiple groups to access resources owned by different group identifiers, such as shared storage used by multiple applications.

Filesystem Access Identity

Read-Only Root Filesystem Interaction with Identity

When readOnlyRootFilesystem is enabled alongside a non-root runAsUser, the combination ensures that even if an attacker gains code execution within the container, the process both lacks write access to the root filesystem and lacks the elevated identity that would otherwise be needed to bypass filesystem permission checks on mounted volumes.

Volume Permission Interactions

The effective identity of a process determines whether it can read or write files on mounted volumes such as emptyDir, configMap, or persistent volumes, since standard Unix permission checks apply based on the process's resolved user and group IDs at runtime, independent of any Kubernetes-level RBAC permissions.

Relationship to Service Account Identity

Distinguishing Runtime Identity from API Identity

Pod Runtime Identity, which governs how a process behaves at the operating system level, is distinct from the Pod's service account identity, which governs how the Pod authenticates to the Kubernetes API server. A Pod may run as a non-privileged operating system user while still holding a service account with broad API permissions, or conversely run as root at the OS level while holding a minimally scoped service account, since the two identity systems operate independently.

Token Mounting and Process Access

Even though the service account token is a Kubernetes-level credential, once mounted into the Pod's filesystem it becomes subject to the same operating system file permission rules as any other file, meaning the container's runtime identity determines which processes within the Pod are able to read that token.

Enforcement Through Pod Security Standards

Restricted Profile Requirements

The Restricted Pod Security Standard mandates that containers set runAsNonRoot: true and disallows explicitly setting runAsUser to zero, formalizing runtime identity hardening as a cluster-enforced requirement rather than a voluntary best practice, ensuring that workloads admitted under this profile cannot execute as the root user regardless of what the container image itself specifies.