[#9646] securityContext initContainers

[dzabel]

• fixes pgadmin4-helm initContainers with hardcoded securityContext does not work on OpenShift #9646
• use renderSecurityContext for initContainers

Summary by CodeRabbit

• New Features
  • Security context settings for container initialization are now configurable via deployment values, allowing customization of SELinux, AppArmor, user/group IDs, and privilege settings instead of using hardcoded defaults.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: ef7f0f12-f5e9-41ea-b4a1-075e212f89ca

📥 Commits

Reviewing files that changed from the base of the PR and between d8a078a and da8c91d.

📒 Files selected for processing (1)

• pkg/helm/templates/deployment.yaml

---

Walkthrough

Helm template modification that removes hardcoded security contexts from two init containers and replaces them with a conditional, values-driven approach. Init containers now respect the same configurable security context settings as the main container.

Changes

Cohort / File(s)	Summary
Init Container Security Context Refactor pkg/helm/templates/deployment.yaml	Removed hardcoded securityContext blocks from modify-config-distro-py-permissions and unset-python3-cli-net-cap init containers. Replaced with conditional renderSecurityContext template driven by Values.containerSecurityContext.enabled, enabling compatibility with OpenShift security policies and other restrictive security constraints.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly references issue #9646 and describes the main change (applying securityContext rendering to initContainers), which aligns with the changeset.
Linked Issues check	✅ Passed	The PR implements the exact fix requested in #9646: replacing hardcoded securityContext in initContainers with conditional rendering via renderSecurityContext template, ensuring parity with main container handling.
Out of Scope Changes check	✅ Passed	All changes are narrowly scoped to the stated objective: removing hardcoded securityContext blocks from initContainers and replacing them with template-based rendering, with no extraneous modifications.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[dpage]

Merged to master as 06300e7 (squashed, with you as author). Thanks @dzabel!

Verified with helm template that this is behaviour-preserving by default: the rendered init-container securityContext is identical to the previous hardcoded block for default values, still honours global.compatibility.appArmor.enabled (no appArmorProfile when false, present when true), and is omitted entirely when containerSecurityContext.enabled=false. helm lint clean. Added a 9.16 release note.