OpenShift Security Context Constraints (SCCs)#

OpenShift's Security Context Constraints (SCCs) govern which security attributes pods may request. The restricted and restricted-v2 SCCs — the defaults for most namespaces — prohibit pods from specifying runAsUser, runAsGroup, or fsGroup, instead assigning dynamic UID/GID values from a per-namespace range at admission time.

This creates a direct conflict with CloudNativePG components that hard-code numeric UID/GID values in their pod security contexts.

CloudNativePG Operator: OpenShift Detection#

The operator auto-detects OpenShift by querying the Kubernetes discovery API for the security.openshift.io/v1 API group (DetectSecurityContextConstraints() in pkg/utils/discovery.go). When SCCs are present, GetPodSecurityContext() returns nil for all PostgreSQL instance pods, delegating full control to the SCC.

The same HaveSecurityContextConstraints() guard applies to PGBouncer deployments and certain plugin commands.

Limitation: This detection is API-resource-based and fails in vcluster environments. A vcluster inside an OpenShift cluster presents as vanilla Kubernetes and does not expose security.openshift.io/v1, so the operator incorrectly assigns UID/GID 26, causing SCC admission rejection 1.

Fix: -1 Sentinel for UID/GID (PR #11243)#

PR #11243 adds an explicit opt-in for SCC-compatible behavior 2:

• Set spec.postgresUID: -1 → runAsUser is omitted from the pod security context
• Set spec.postgresGID: -1 → both runAsGroup and fsGroup are omitted

This allows OpenShift (or any platform using dynamic UID assignment) to inject its own values, regardless of whether the API-based detection succeeds. It also fixes cloudnative-pg#11245 for vcluster deployments.

Default values (RunAsUser: 26, RunAsGroup: 26, FSGroup: 26) are documented in the Pod Security Context knowledge base article.

plugin-barman-cloud: Manifest Incompatibilities#

The Barman Cloud plugin manifests ship with two OpenShift-incompatible assumptions:

1. Hard-coded UID/GID#

kubernetes/deployment.yaml and the generated manifest.yaml both specify 3 4:

securityContext:
  runAsGroup: 10001
  runAsUser: 10001

OpenShift's restricted SCC rejects pods that declare an explicit runAsUser outside the namespace's allowed UID range. No OpenShift SCC override files exist in the repository.

2. Hard-coded cnpg-system Namespace#

kubernetes/kustomization.yaml pins the namespace to cnpg-system 5, and this is baked into manifest.yaml in a dozen locations 4. RBAC bindings also reference cnpg-system explicitly 6 7 8. This blocks deployments where the operator runs in a different namespace, a common pattern in OpenShift.

Status#

As of mid-2026, the E2E test plan for plugin-barman-cloud explicitly excludes OpenShift because of these issues 9:

"OpenShift is excluded given that the manifest installation of plugin-barman-cloud is not compatible with OpenShift by default (fixed securityContext runAsGroup/runAsUser 1001, fixed cnpg-system namespace), and an OLM installation for plugin-barman-cloud is not yet available."

An OLM-based distribution (tracked in plugin-barman-cloud issue #554) is the intended long-term path for proper OpenShift support.

Workarounds & Mitigations#

Key Source References#