Pod Security Context in CloudNativePG#

Overview#

CloudNativePG applies a default PodSecurityContext to every PostgreSQL instance pod. When users supply a custom spec.podSecurityContext, the operator uses a selective backfill strategy: it merges only RunAsUser, RunAsGroup, and SeccompProfile from defaults into the user-provided context, while leaving FSGroup and RunAsNonRoot untouched.

This behavior is implemented in GetPodSecurityContext in pkg/specs/pods.go and was introduced by PR #6614.

Default Security Context#

When spec.podSecurityContext is not set, the operator builds the following defaults 1:

DefaultPostgresUID and DefaultPostgresGID are both 26, matching the UID/GID of the postgres system user in typical container images 2. These can be overridden via spec.postgresUID / spec.postgresGID in the Cluster spec.

On OpenShift, the entire PodSecurityContext is set to nil because security constraints are inherited from the restricted SecurityContextConstraints (SCC) 3.

Selective Backfill Behavior#

When spec.podSecurityContext is set, the operator deep-copies the user's context and backfills only three fields if they are nil 4:

• RunAsUser ← filled from GetPostgresUID() if not set
• RunAsGroup ← filled from GetPostgresGID() if not set
• SeccompProfile ← filled from GetSeccompProfile() if not set

FSGroup and RunAsNonRoot are NOT backfilled. If the user provides a PodSecurityContext without setting these fields, they will remain nil in the resulting context 5.

Why FSGroup and RunAsNonRoot are excluded#

• FSGroup is storage-specific. Different storage backends (and especially OpenShift's restricted SCC) may reject or conflict with a forced fsGroup value. Leaving it unset lets users—and the platform—control volume ownership explicitly.
• RunAsNonRoot is a binary security policy decision. The operator does not silently enforce this policy when a user has opted into providing their own security context; they may have a valid reason to leave it unset (e.g., PSA policy enforcement at namespace level already covers this).

The deep-copy prevents mutation of the cluster spec object 6.

Test Coverage#

The behavior is explicitly validated in pkg/specs/pods_test.go:

• No custom context → all five default fields are set 7
• Partial custom context (only RunAsUser set) → RunAsGroup and SeccompProfile are backfilled; FSGroup and RunAsNonRoot remain nil 5
• Custom SeccompProfile on spec.seccompProfile → honored when podSecurityContext.SeccompProfile is nil; FSGroup and RunAsNonRoot still remain nil 8
• User explicitly sets FSGroup and RunAsNonRoot → preserved as-is 9

API Fields#

Defined in api/v1/cluster_types.go:

• spec.podSecurityContext (*corev1.PodSecurityContext, optional) — overrides the operator's default pod-level security context. No effect when SecurityContextConstraints are present.
• spec.seccompProfile (*corev1.SeccompProfile, optional) — sets a custom seccomp profile for all pods and containers; defaults to RuntimeDefault. Consulted by GetSeccompProfile() when building both pod and container security contexts.
• spec.postgresUID / spec.postgresGID (int64, optional) — custom UID/GID used in RunAsUser, RunAsGroup, and (in the full-default path) FSGroup.

Container-level security context is handled separately via GetSecurityContext() (configured via spec.securityContext).

Key Source References#