feat: Enhance Security Context Compatibility and OpenShift Support + Add Dynamic Configuration Options to Vault Helm Chart

[JuryA]

Overview

This pull request introduces significant updates to the Vault Helm chart, focusing on improving security context compatibility, adding new configuration options, and enhancing OpenShift support. The changes include the addition of dynamic security context rendering, new parameters for container and pod configurations, and updates to the StatefulSet template to ensure compatibility across different platforms.

Security Context Enhancements:

• Added vault.compatibility.renderSecurityContext helper in vault/templates/_compatibility.tpl to dynamically adapt security contexts based on the deployment platform (e.g., OpenShift). This includes removing incompatible fields like fsGroup, runAsUser, and runAsGroup when necessary.
• Updated security contexts for containers in vault/templates/statefulset.yaml to use the new compatibility helper, ensuring platform-specific adjustments for vault-config, vault-unsealer, vault-configurer, and prometheus-statsd-exporter. [1] [2] [3] [4]

OpenShift Support:

• Introduced the global.openshift parameter in vault/values.yaml, allowing values true, false, or auto to specify or detect OpenShift deployment automatically.
• Added logic in vault.compatibility.renderSecurityContext to adapt security contexts for OpenShift's restricted-v1 SCC.

Helm Chart Configuration:

• Expanded the configurable parameters in vault/README.md to include new options such as containerSecurityContext, podSecurityContext, certManager, and priorityClassName. These additions enhance flexibility for deployments and improve security.

StatefulSet Template Updates:

• Replaced hardcoded security contexts in vault/templates/statefulset.yaml with calls to compatibility helpers, ensuring dynamic adjustments based on platform-specific requirements. [1] [2]

Bank-Vaults Integration:

• Added vault.bank-vaults.containerSecurityContext helper in vault/templates/_helpers.tpl to include the IPC_LOCK capability when vault.config.disable_mlock is not enabled. This ensures proper functionality of Bank-Vaults with enhanced security.

Fixes #275 (partly), bank-vaults/bank-vaults#1442

Notes for reviewer

Signed-off-by: Jiří Altman [email protected]

[Copilot]

Pull Request Overview

This PR enhances the Vault Helm chart with dynamic security context handling, adds new configuration options, and improves OpenShift compatibility.

• Introduces a renderSecurityContext helper and replaces hardcoded securityContexts in the StatefulSet.
• Adds global.openshift detection, omitEmptySeLinuxOptions, and per-pod/container securityContext parameters in values.yaml.
• Updates README and helper templates to document and wire in the new options.

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
vault/values.yaml	Added global.compatibility, podSecurityContext, and containerSecurityContext parameters; updated component blocks.
vault/templates/statefulset.yaml	Replaced static securityContext blocks with calls to compatibility helpers.
vault/templates/_helpers.tpl	Added vault.bank-vaults.containerSecurityContext helper.
vault/templates/_compatibility.tpl	Added isOpenshift and renderSecurityContext compatibility logic.
vault/README.md	Expanded chart values table to include new security and configuration options.

Comments suppressed due to low confidence (4)

vault/values.yaml:368

• This description is applied to vaultConfig.containerSecurityContext (the vault-config init container), but mentions ‘unsealer’. Update the text to reference the vault-config container.

# -- (object) SecurityContext capabilities to add to the unsealer container

vault/values.yaml:387

• This description is under vaultConfigurer.containerSecurityContext and should reference the vault-configurer container instead of ‘unsealer’.

# -- (object) SecurityContext capabilities to add to the unsealer container

vault/README.md:209

• The description for vaultConfig.containerSecurityContext should mention the vault-config init container, not the unsealer.

| `vaultConfig.containerSecurityContext` | object | `{"enabled":false}` | SecurityContext capabilities to add to the unsealer container |

vault/README.md:211

• The description for vaultConfigurer.containerSecurityContext should refer to the vault-configurer container rather than the unsealer.

| `vaultConfigurer.containerSecurityContext` | object | `{"enabled":false}` | SecurityContext capabilities to add to the unsealer container |

[JuryA]

@lgecse Have you had a chance to review my code request?

[csatib02]

LGTM!

[BlaxXGit]

✅ Verified: Security Context Bug Fixed

I've tested your latest commits and can confirm that the security context bug I reported has been successfully resolved. Great work on implementing the fix!

🧪 Test Results

Test Case 1: disable_mlock: true with drop: ALL capabilities

helm template vault . -f test-security.yaml | grep -A 5 -B 5 "IPC_LOCK"
# Result: No matches found ✅

Test Case 2: disable_mlock: false with drop: ALL capabilities

securityContext:
  capabilities:
    add:
    - IPC_LOCK      # ✅ Correctly added when needed
    drop:
    - ALL           # ✅ User config preserved

🎯 Key Improvements Confirmed

1. IPC_LOCK logic works correctly: Only added when disable_mlock: false
2. User capabilities preserved: drop: ALL no longer gets overwritten
3. mergeOverwrite approach: Clean implementation that maintains forward compatibility

The vault.bank-vaults.containerSecurityContext helper now properly handles both scenarios while preserving all user-defined security context properties.

Thanks for addressing this critical security configuration issue! 🙌

[JuryA]

@ramizpolic @csatib02 Could you please prioritise completing the review? I've resolved all outstanding issues, with @BlaxXGit already confirming and approving them. I'm heading off on an extended trip without access to a computer, so I'd really appreciate finalising this beforehand.

If that’s not possible, you may need to handle the merge independently later, which I'd like to avoid if we can.