OSAC-4912: fix bundled OpenBao Deployment SCC rejection

[ygalblum]

Summary

• The bundled OpenBao Deployment in the osac Helm chart
  (osac-installer/charts/osac/templates/bundled-openbao.yaml) hardcoded
  pod-level securityContext.runAsUser: 100, runAsGroup: 1000, and
  fsGroup: 1000. On OpenShift, the pod's ServiceAccount (default) is
  only authorized for the restricted-v2 SCC, which enforces
  MustRunAsRange from the namespace's allocated UID range, not these
  hardcoded values — so the ReplicaSet could never create a pod
  (FailedCreate / SCC admission rejection).
• Fix removes the hardcoded runAsUser/runAsGroup/fsGroup, keeping
  only runAsNonRoot: true — matching the pattern already used by other
  regular Deployments in the chart (e.g. fulfillment-grpc-server), which
  let OpenShift's SCC admission auto-assign a UID/fsGroup from the
  namespace's allocated range. OpenBao's bao server -dev mode uses only
  emptyDir volumes, so there is no fixed-ownership requirement that would
  need a pinned UID/GID.
• This is a separate bug from OSAC-4911 (bundledVault values-file
  placement) — that PR (OSAC-4911: move bundledVault config to instance.yaml for CI profiles #750) only just fixed enabling OpenBao at all,
  which exposed this pod-admission bug for the first time.

Test plan

• Verified fix live on a running OpenShift dev cluster: helm upgrade --install osac succeeded and the openbao pod came up healthy (2/2
  Running, server and bootstrap containers), where before the fix
  the ReplicaSet was permanently stuck in FailedCreate due to SCC
  rejection.
• helm template osac charts/osac -f values/vmaas-ci/instance.yaml --set bundledVault.enabled=true --set bundledVault.devRootToken=dev-root-token confirms the rendered
  openbao Deployment's pod securityContext now only sets
  runAsNonRoot: true.
• yamllint --strict . passes (output identical before/after change).
• pre-commit run --all-files passes.
• make helm-lint / make helm-validate fail only on a pre-existing,
  unrelated service.externalHostname/internalHostname schema
  error in default values.yaml — confirmed present on main before
  this change too (not caused by this fix).

Fixes: https://redhat.atlassian.net/browse/OSAC-4912

Assisted-by: Claude Code noreply@anthropic.com

Changes

• Deployment: Removed hardcoded runAsUser, runAsGroup, and fsGroup values from the bundled OpenBao Deployment.
• Retained runAsNonRoot: true.
• OpenShift SCC admission can assign IDs from the namespace range.
• This addresses pod creation failures with restricted-v2 SCC.
• No API, controller, database, authentication, test, or documentation changes.

Compatibility

• OpenShift may assign different runtime user and group IDs.
• No public API changes are expected.
• Helm validation retains a pre-existing schema error.

Risk classification

• risk:ship — The change is small, preserves non-root execution, and reported OpenShift deployment and validation checks passed.

[openshift-ci-robot]

@ygalblum: This pull request references OSAC-4912 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "5.1.0" version, but no target version was set.

Details

In response to this:

Summary

• The bundled OpenBao Deployment in the osac Helm chart
  (osac-installer/charts/osac/templates/bundled-openbao.yaml) hardcoded
  pod-level securityContext.runAsUser: 100, runAsGroup: 1000, and
  fsGroup: 1000. On OpenShift, the pod's ServiceAccount (default) is
  only authorized for the restricted-v2 SCC, which enforces
  MustRunAsRange from the namespace's allocated UID range, not these
  hardcoded values — so the ReplicaSet could never create a pod
  (FailedCreate / SCC admission rejection).
• Fix removes the hardcoded runAsUser/runAsGroup/fsGroup, keeping
  only runAsNonRoot: true — matching the pattern already used by other
  regular Deployments in the chart (e.g. fulfillment-grpc-server), which
  let OpenShift's SCC admission auto-assign a UID/fsGroup from the
  namespace's allocated range. OpenBao's bao server -dev mode uses only
  emptyDir volumes, so there is no fixed-ownership requirement that would
  need a pinned UID/GID.
• This is a separate bug from OSAC-4911 (bundledVault values-file
  placement) — that PR (OSAC-4911: move bundledVault config to instance.yaml for CI profiles #750) only just fixed enabling OpenBao at all,
  which exposed this pod-admission bug for the first time.

Test plan

• Verified fix live on a running OpenShift dev cluster: helm upgrade --install osac succeeded and the openbao pod came up healthy (2/2
  Running, server and bootstrap containers), where before the fix
  the ReplicaSet was permanently stuck in FailedCreate due to SCC
  rejection.
• helm template osac charts/osac -f values/vmaas-ci/instance.yaml --set bundledVault.enabled=true --set bundledVault.devRootToken=dev-root-token confirms the rendered
  openbao Deployment's pod securityContext now only sets
  runAsNonRoot: true.
• yamllint --strict . passes (output identical before/after change).
• pre-commit run --all-files passes.
• make helm-lint / make helm-validate fail only on a pre-existing,
  unrelated service.externalHostname/internalHostname schema
  error in default values.yaml — confirmed present on main before
  this change too (not caused by this fix).

Fixes: https://redhat.atlassian.net/browse/OSAC-4912

Assisted-by: Claude Code noreply@anthropic.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ygalblum

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• osac-installer/OWNERS [ygalblum]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: a47859ab-4310-49fe-8907-9f31642d5b2c

📥 Commits

Reviewing files that changed from the base of the PR and between 7ca81db and 01c06f0.

📒 Files selected for processing (1)

• osac-installer/charts/osac/templates/bundled-openbao.yaml

💤 Files with no reviewable changes (1)

• osac-installer/charts/osac/templates/bundled-openbao.yaml

Included review availability: Your plan provides up to 12 included reviews per hour; 10 remain after this review.

---

Walkthrough

The bundled OpenBao Deployment pod security context no longer sets fixed user, group, or filesystem group IDs. It continues to require a non-root process.

Changes

OpenBao pod security context

Layer / File(s)	Summary
Remove fixed pod identity settings osac-installer/charts/osac/templates/bundled-openbao.yaml	The security context retains runAsNonRoot: true and removes runAsUser, runAsGroup, and fsGroup.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Merge Risk: ⚪ Minimal · up to 01c06

The deployment now allows OpenShift to assign non-root identity values while retaining non-root enforcement. No current merge-blocking risk remains.

Suggested labels: risk:ask

🚥 Pre-merge checks | ✅ 11

✅ Passed checks (11 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the issue and the main change: fixing SCC rejection for the bundled OpenBao Deployment.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
No-Hardcoded-Secrets	✅ Passed	PASS: The commit changes one template and contains only three deletions (runAsUser, runAsGroup, and fsGroup). It adds no literals or configuration values. The remaining BAO_TOKEN and `devRootT…
No-Weak-Crypto	✅ Passed	PASS. The pull request changes only three pod security-context fields in bundled-openbao.yaml: it removes runAsUser, runAsGroup, and fsGroup. The complete commit diff introduces no MD5, SHA1, …
No-Injection-Vectors	✅ Passed	PASS: The commit changes only osac-installer/charts/osac/templates/bundled-openbao.yaml. It deletes hardcoded runAsUser, runAsGroup, and fsGroup fields. It adds no SQL concatenation, shell exe…
Container-Privileges	✅ Passed	The only change removes runAsUser, runAsGroup, and fsGroup from the OpenBao pod. The pod still sets runAsNonRoot: true. Both OpenBao containers set allowPrivilegeEscalation: false and drop a…
No-Sensitive-Data-In-Logs	✅ Passed	PASS: The commit changes only three pod securityContext fields. It adds no logging statements or log output. Existing bootstrap messages are unchanged and do not print token, password, API key, PII, h…
Ai-Attribution	✅ Passed	AI use is declared in the PR and commit. HEAD contains the trailer Assisted-by: Claude Code <noreply@anthropic.com>. No Co-Authored-By trailer is present.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

E2E on CodeRabbit approval

CodeRabbit APPROVED — starting expensive e2e (PR run replay).

• Started: 3/3

[ygalblum]

Closing as it is addressed in #730