Skip to content

Helm Chart: Openshift SecurityContextConstraints #21652

@mtdoughty

Description

@mtdoughty

The helm Chart currently detects if Minio is being deployed on OpenShift and deploy 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

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.

Current Behavior

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

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

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?

Steps to Reproduce (for bugs)

Install Minio via helm on OpenShift:

helm install minio minio/minio

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.

Regression

No

Your Environment

Helm chart version 5.4.0

Openshift version 4.18

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions