Deployment issues on OpenShift due to container securityContext

[BlueCog]

Summary

When deploying the CloudNativePG Helm chart on OpenShift, we encountered deployment failures caused by the container-level securityContext specified in the chart's values.yaml. OpenShift's security policies restrict the use of certain securityContext fields, leading to conflicts that prevent the pods from starting.

Details

• The securityContext at the container level includes hardcoded runAsUser and runAsGroup values.
• OpenShift assigns user IDs (UIDs) and group IDs (GIDs) dynamically for security reasons.
• Specifying runAsUser and runAsGroup in the container securityContext causes permission issues on OpenShift. -The pods fail to start with errors related to security context constraints.

Proposed Solution:

• Introduce a new configuration option to make the container securityContext optional.
• Add a boolean flag enableSecurityContex under containerSecurityContext in values.yaml.
• Modify deployment.yaml to include the container securityContext only if enableSecurityContext is true.
• Default the flag to true to preserve existing behavior for users not affected by this issue.

Pull Request:

A pull request implementing this solution has been submitted: https://github.com/cloudnative-pg/charts/pull/445

Additional Context:

We are not utilizing the Operator Lifecycle Manager (OLM) installation method for deploying the CloudNativePG operator. Instead, we have an internal Lifecycle Management (LCM) process that leverages tools like Renovate and ArgoCD to manage our deployments.

[sxd]

Hello @BlueCog

The chart to install the operator it's not meant to be used with OpenShift, for that, there's a supported OLM package, the chart should never be used on OpenShift

Regards,

[BlueCog]

The chart to install the operator it's not meant to be used with OpenShift, for that, there's a supported OLM package, the chart should never be used on OpenShift

Regards,

Thank you for your response.

I wanted to confirm whether this is the official stance regarding the usage of the Helm chart on OpenShift. In our experience, we have successfully installed the CloudNativePG operator on OpenShift with minimal adjustments. Post-installation, we have been able to provision databases and utilize the operator's features without any issues.

Our organization operates in an air-gapped environment, which means that utilizing the Operator Lifecycle Manager (OLM) does not provide direct benefits for us. Implementing OLM would require additional efforts to mirror and maintain the OLM packages within our environment. Moreover, OLM does not fit well with our stringent automated update policy, which is efficiently managed through standalone images and Helm charts, along with tools like Renovate and ArgoCD.

By deploying via Helm charts, we can:

• Maintain Consistency: Our lifecycle management process ensures all components are updated and deployed consistently.
• Automate Updates: Tools like Renovate help us keep dependencies current without manual intervention.
• Integrate Seamlessly: Helm charts align with our existing CI/CD pipelines and infrastructure.

Given these factors, having the option to deploy the operator using Helm charts is highly beneficial for us. The changes proposed in the pull request aim to enhance the Helm chart's compatibility with OpenShift by making the container securityContext optional. This modification does not affect users who deploy in environments without such constraints but provides flexibility for those who do.

We would appreciate it if you could consider our use case and the proposed changes. Supporting the Helm chart deployment on OpenShift would greatly assist organizations like ours that rely on Helm for deployment and have specific operational requirements.

Thank you for your time and consideration. We look forward to your feedback.