Minio Helm Chart On OpenShift: SecurityContextConstraints

Oct 22, 2025 by SLV Team 58 views

Minio Helm Chart and OpenShift SecurityContextConstraints Discussion

The Minio Helm Chart currently detects if Minio is being deployed on OpenShift and deploys an additional SecurityContextConstraints resource if it is. This requires admin privileges over and above what you would expect a typical developer / OpenShift project admin to have.

Maybe someone with more history can explain the original thinking here, but it seems that we are adding a new SecurityContextConstraints to OpenShift that allows Minio to run with a more relaxed SecurityContext when we could instead just deploy Minio with a tighter SecurityContext that conforms to standard / existing ones?

We are able to run Minio without allowPrivilegeEscalation and with random UIDs/fsGroup that OpenShift requires (but perhaps there are some features that require this that I am not aware of.)

Expected Behavior

Expected behavior for the Helm chart should automatically deploy Minio in a way that is compatible with a standard OpenShift deployment, without needing admin privileges to install, or requests to run at pods with elevated privileges. The goal is to make the installation process seamless and secure for users deploying Minio on OpenShift.

To achieve this, the chart should be configured to work within the constraints of OpenShift's security policies without requiring elevated permissions. This means avoiding the creation of custom SecurityContextConstraints that necessitate cluster-admin privileges. Instead, the chart should leverage the existing security context options provided by OpenShift to ensure compatibility and ease of deployment.

The desired outcome is a Minio deployment that adheres to OpenShift's security standards, allowing developers and project administrators to install and manage Minio without needing to request special permissions or make complex configurations. This would greatly simplify the deployment process and make Minio more accessible to a wider range of users on OpenShift.

Additionally, the chart should be configurable to allow users to further customize the security context if needed, but the default configuration should be secure and compatible with OpenShift out of the box. This would provide flexibility for advanced users while ensuring a smooth and secure experience for those who prefer the default settings.

Current Behavior

When installing the chart with default settings in a standard Openshift Project you get a permissions error that:

helm install minio minio/minio
Error: INSTALLATION FAILED: rendered manifests contain a resource that already exists. Unable to continue with install: could not get information about the resource SecurityContextConstraints "minio" in namespace "": securitycontextconstraints.security.openshift.io "minio" is forbidden: User "testUser" cannot get resource "securitycontextconstraints" in API group "security.openshift.io" at the cluster scope

The current behavior of the Minio Helm chart on OpenShift results in a permissions error during installation. This error occurs because the chart attempts to create a SecurityContextConstraints resource, which requires cluster-admin privileges. Standard OpenShift projects do not grant these elevated permissions to regular users or service accounts, leading to the installation failure.

The error message indicates that the user attempting to install the chart lacks the necessary permissions to create or modify SecurityContextConstraints resources. This is a common issue in OpenShift environments where security is tightly controlled, and users are typically restricted to managing resources within their assigned projects.

This behavior is problematic because it prevents developers and project administrators from easily deploying Minio using the Helm chart. It forces them to either request elevated permissions from the cluster administrator or find alternative deployment methods that do not rely on creating custom SecurityContextConstraints. Both of these options add complexity and friction to the deployment process.

Moreover, the current behavior contradicts the principle of least privilege, as it requires the chart to request more permissions than are strictly necessary for Minio to function correctly. This can raise security concerns and make it more difficult to secure the OpenShift environment.

Possible Solution

I think templates/securitycontextconstraints.yaml could probably be removed completely.

Then in templates/deployment.yaml and templates/statefulset.yaml (and anywhere else that we set the security context) we could just make sure the runAsUser and fsGroup, runAsGroup are not set on OpenShift installs (as openshift will; automatically set these to suitable values for the project). E.g. the securityContext part of the template could become something like:

 {{- if and .Values.securityContext.enabled .Values.persistence.enabled }}
 securityContext:
 {{- if .Capabilities.APIVersions.Has "security.openshift.io/v1" }}
 {{ omit .Values.securityContext "enabled" "runAsUser" "runAsGroup" "fsGroup" | toYaml | nindent 8 }}
 {{- else }}
 {{ omit .Values.securityContext "enabled" | toYaml | nindent 8 }}
 {{- end }}
 {{- end }}

I would be happy to create a PR, if this solution would be acceptable?

The proposed solution involves removing the SecurityContextConstraints resource from the Helm chart and adjusting the security context settings in the deployment and statefulset templates. By removing the SecurityContextConstraints resource, the chart would no longer require cluster-admin privileges to install, making it more accessible to users with standard OpenShift project permissions.

Instead of creating a custom SecurityContextConstraints, the solution suggests relying on OpenShift's built-in security mechanisms to manage the security context of the Minio pods. This can be achieved by ensuring that the runAsUser, fsGroup, and runAsGroup parameters are not explicitly set in the deployment and statefulset templates when deploying on OpenShift.

OpenShift automatically assigns suitable values for these parameters based on the project's security policies. By omitting these parameters, the Minio pods will inherit the appropriate security context from the OpenShift environment, ensuring compatibility and security without requiring elevated permissions.

This approach aligns with the principle of least privilege and simplifies the deployment process. It also reduces the risk of security vulnerabilities by relying on OpenShift's established security mechanisms.

To implement this solution, the templates/securitycontextconstraints.yaml file would be removed, and the templates/deployment.yaml and templates/statefulset.yaml files would be modified to conditionally omit the runAsUser, fsGroup, and runAsGroup parameters when deploying on OpenShift. The provided code snippet demonstrates how this can be achieved using Helm's templating capabilities.

Steps to Reproduce (for bugs)

Install Minio via helm on OpenShift:

helm install minio minio/minio

To reproduce the bug, follow these steps:

Set up an OpenShift cluster with standard project permissions.
Install the Minio Helm chart using the default settings:
```
helm install minio minio/minio
```
Observe the error message indicating that the user lacks the necessary permissions to create the SecurityContextConstraints resource.

This will confirm that the current behavior of the chart requires cluster-admin privileges and is not compatible with standard OpenShift project permissions.

By following these steps, you can easily reproduce the issue and verify the effectiveness of the proposed solution.

Context

We are looking to use the Minio chart as a subchart to another chart. We would like to minimise the amount of specific configuration that is need for different cluster types, while ensuring that the default configuration is as secure as possible.

The context for this issue is the desire to use the Minio chart as a subchart within a larger application deployment. The goal is to create a seamless and secure deployment process that minimizes the need for specific configuration based on the underlying cluster type.

In this scenario, it is crucial that the Minio chart can be easily integrated into other applications without requiring extensive modifications or manual intervention. This means that the chart must be compatible with a wide range of environments, including OpenShift, and should not require elevated permissions or custom security configurations.

By addressing the SecurityContextConstraints issue, the Minio chart can be made more portable and easier to use in various deployment scenarios. This would greatly simplify the process of integrating Minio into other applications and reduce the overall complexity of the deployment process.

Additionally, ensuring that the default configuration is as secure as possible is a key consideration. This means that the chart should be configured to adhere to best practices for security and should not introduce any unnecessary risks or vulnerabilities.

Regression

This is not a regression. It is a pre-existing issue.

Your Environment

Helm chart version 5.4.0

Openshift version 4.18

The environment consists of Helm chart version 5.4.0 and Openshift version 4.18.