PB-16197 | added SCC hardening for px-backup

[vk-px]

Summary

This PR tightens SCC and pod security handling for PX-Backup on OpenShift, with focus on the pxcentral-apiserver path and the post-install hook ServiceAccount.

The goal is to make the core PX-Backup / PX-Central deployment work cleanly in a restricted OpenShift namespace, without requiring broader SCCs than necessary.

This PR also captures an important validation finding: telemetry is a separate exception path and requires at least nonroot / nonroot-v2, because edge-envoy runs with a fixed non-root UID.

Problem

On OpenShift, PX-Backup installation was observed to change the namespace pod security posture from restricted to privileged during deployment. This is the behavior tracked in PB-16433.

The related fix direction discussed internally was to avoid pod security labels changing from restricted to privileged during PX-Backup install.

In baseline validation using the unmodified chart, installation into a pre-created restricted namespace was accepted by the cluster, but the deployment did not converge cleanly. Core components such as pxcentral-backend, pxcentral-frontend, and pxcentral-lh-middleware did not stabilize in that setup.

What this PR changes

This PR tightens the SCC and securityContext posture for the core install path, specifically around:

• pxcentral-apiserver
• post-install hook ServiceAccount and hook execution path
• associated PX-Central components that should run under restricted-v2

The intent is to keep the core deployment on the least-privilege SCC possible and avoid unnecessary dependence on broader SCCs such as anyuid for the normal PX-Backup installation flow.

Validation

Validation was performed using a manually created OpenShift namespace with restricted pod security enforcement and SCC-to-PSA label sync disabled.

Baseline result with the unmodified chart:

• installation started successfully
• deployment did not converge cleanly
• key PX-Central components failed to become healthy in the restricted namespace

Observed Helm install output from the baseline run:

helm install px-central /Users/vk/Documents/programming/helm/charts/px-central --namespace px-backup-restricted \
  --set persistentStorage.enabled=true,persistentStorage.storageClassName=px-csi-db,pxbackup.enabled=true
I0715 13:32:56.855483   35590 warnings.go:107] "Warning: would violate PodSecurity \"restricted:latest\": allowPrivilegeEscalation != false (container \"pxcentral-apiserver\" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container \"pxcentral-apiserver\" must set securityContext.capabilities.drop=[\"ALL\"]), runAsNonRoot != true (pod or container \"pxcentral-apiserver\" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container \"pxcentral-apiserver\" must set securityContext.seccompProfile.type to \"RuntimeDefault\" or \"Localhost\")"
I0715 13:32:57.574538   35590 warnings.go:107] "Warning: would violate PodSecurity \"restricted:latest\": allowPrivilegeEscalation != false (container \"pxcentral-post-setup\" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container \"pxcentral-post-setup\" must set securityContext.capabilities.drop=[\"ALL\"]), runAsNonRoot != true (pod or container \"pxcentral-post-setup\" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container \"pxcentral-post-setup\" must set securityContext.seccompProfile.type to \"RuntimeDefault\" or \"Localhost\")"
NAME: px-central
STATUS: deployed

Observed pod behavior from the baseline run:

pxcentral-backend-7b88c65686-v2h4h         0/1     CreateContainerConfigError
pxcentral-frontend-6cd6f9c7d8-qcv5v        0/1     CreateContainerConfigError
pxcentral-lh-middleware-58ddd9464f-2hpz5   0/1     CrashLoopBackOff
px-backup-59ccdc8c59-pwdfd                 1/1     Running

Result with the changes in this PR:

• pxcentral-apiserver came up successfully
• pxcentral-backend came up successfully
• pxcentral-frontend came up successfully
• pxcentral-lh-middleware came up successfully
• px-backup came up successfully
• pxcentral-post-install-hook completed successfully

Observed pod behavior with the latest changes:

NAME                                          READY   STATUS      RESTARTS        AGE
alertmanager-px-backup-alertmanager-0         2/2     Running     0               3m37s
alertmanager-px-backup-alertmanager-1         2/2     Running     0               3m37s
prometheus-operator-86575656c7-x2k9m          1/1     Running     0               3m38s
prometheus-px-backup-dashboard-prometheus-0   2/2     Running     0               3m37s
prometheus-px-backup-dashboard-prometheus-1   2/2     Running     0               3m37s
px-backup-59ccdc8c59-fcd22                    1/1     Running     2 (3m15s ago)   3m38s
pxc-backup-mongodb-0                          1/1     Running     0               3m38s
pxc-backup-mongodb-1                          1/1     Running     0               3m38s
pxc-backup-mongodb-2                          1/1     Running     0               3m38s
pxcentral-apiserver-6d6756d9d5-75qp4          1/1     Running     0               3m38s
pxcentral-backend-7b5fb57496-xzfzc            1/1     Running     0               62s
pxcentral-frontend-66b9979886-9vvjj           1/1     Running     0               62s
pxcentral-keycloak-0                          1/1     Running     0               3m38s
pxcentral-keycloak-postgresql-0               1/1     Running     0               3m38s
pxcentral-lh-middleware-58ddd9464f-rnh6k      1/1     Running     0               62s
pxcentral-mysql-0                             1/1     Running     0               3m38s
pxcentral-post-install-hook-xqcp2             0/1     Completed   0               3m44s

In the restricted validation namespace, all observed core pods were admitted under restricted-v2, including:

• pxcentral-apiserver
• pxcentral-backend
• pxcentral-frontend
• pxcentral-lh-middleware
• pxcentral-post-install-hook
• px-backup
• MongoDB, MySQL, Keycloak, Prometheus, and Alertmanager components

Observed SCC admission output:

POD                                           SCC
alertmanager-px-backup-alertmanager-0         restricted-v2
alertmanager-px-backup-alertmanager-1         restricted-v2
prometheus-operator-86575656c7-x2k9m          restricted-v2
prometheus-px-backup-dashboard-prometheus-0   restricted-v2
prometheus-px-backup-dashboard-prometheus-1   restricted-v2
px-backup-59ccdc8c59-fcd22                    restricted-v2
pxc-backup-mongodb-0                          restricted-v2
pxc-backup-mongodb-1                          restricted-v2
pxc-backup-mongodb-2                          restricted-v2
pxcentral-apiserver-6d6756d9d5-75qp4          restricted-v2
pxcentral-backend-7b5fb57496-xzfzc            restricted-v2
pxcentral-frontend-66b9979886-9vvjj           restricted-v2
pxcentral-keycloak-0                          restricted-v2
pxcentral-keycloak-postgresql-0               restricted-v2
pxcentral-lh-middleware-58ddd9464f-rnh6k      restricted-v2
pxcentral-mysql-0                             restricted-v2
pxcentral-post-install-hook-xqcp2             restricted-v2

This validates that the tightened core deployment path works under restricted-v2 in the tested setup.

Telemetry finding

Telemetry should be treated separately from the core SCC tightening in this PR.

Internal findings from PB-16295 show that edge-envoy runs as fixed UID 10001, while restricted-v2 assigns a UID from the namespace range. Because the runtime UID is not 10001, Envoy encounters permission failures during startup, cannot complete its required config/certificate flow, and telemetry registration does not complete.

The least-privilege resolution for telemetry is nonroot / nonroot-v2, which allows fixed non-root UIDs without opening access as broadly as anyuid.

Scope

This PR is intended to harden the core PX-Backup / PX-Central install path for OpenShift restricted environments by tightening SCC usage for the API server and post-install hook path.

Telemetry is not fully covered by a pure restricted-v2 model and should be treated as a separate minimum-access path:

• core PX-Backup / PX-Central: restricted-v2
• telemetry: nonroot / nonroot-v2
• avoid anyuid where nonroot is sufficient

Result

After these changes:

• the restricted namespace validation succeeds for the core deployment path
• pxcentral-apiserver and the post-install flow no longer block clean startup in the restricted test setup
• core workloads can be admitted under restricted-v2
• telemetry remains a separate SCC consideration and needs nonroot minimum due to fixed-UID requirements

Suggested reviewer note

This PR focuses on SCC tightening for the core PX-Backup / PX-Central installation path on OpenShift. It does not attempt to force telemetry onto restricted-v2; telemetry has a separate fixed-UID requirement and needs nonroot / nonroot-v2 as the least-privilege option.