All charts should be installable under the `restricted` Pod Security Standard

[gcapizzi]

Name and Version

All charts. In my case, I have looked at the latest versions of MySQL and RabbitMQ.

What is the problem this feature will solve?

In order to install a chart on a cluster that enforces the restricted Pod Security Standard, some specific properties need to be set on the securityContexts in its pods/containers. Not all charts expose these values: see for example RabbitMQ.

What is the feature you are proposing to solve the problem?

I propose all charts expose all necessary values to allow users to install them under the restricted Pod Security Standard, if they wish to do so. Optionally, we should consider defaulting these values so that charts can be installed under restricted out of the box.

What alternatives have you considered?

Due to how the charts I've looked at are implemented, users can already pass these values and get them interpolated. See for example how the RabbitMQ chart does it:

{{- if .Values.containerSecurityContext.enabled }}
securityContext: {{- omit .Values.containerSecurityContext "enabled" | toYaml | nindent 12 }}
{{- end }}

This works, but it's impossible for the user to tell, unless they inspect the implementation. Not explicitly exposing and documenting the values also doesn't offer any guarantee against future changes in the implementation.

[javsalgar]

Hi!

Thank you for the feedback. This is something that we have in our backlog. Actually, the new charts that we're developing already include support for restricted systems.

Check for example Deepspeed, which has the following:

  ## Configure Pods Security Context
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod
  ## @param client.podSecurityContext.enabled Enabled Client pods' Security Context
  ## @param client.podSecurityContext.fsGroup Set Client pod's Security Context fsGroup
  ## @param client.podSecurityContext.seccompProfile.type Set Client container's Security Context seccomp profile
  ##
  podSecurityContext:
    enabled: true
    fsGroup: 1001
    seccompProfile:
      type: "RuntimeDefault"
  ## Configure Container Security Context
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod
  ## @param client.containerSecurityContext.enabled Enabled Client containers' Security Context
  ## @param client.containerSecurityContext.runAsUser Set Client containers' Security Context runAsUser
  ## @param client.containerSecurityContext.runAsGroup Set Client containers' Security Context runAsGroup
  ## @param client.containerSecurityContext.runAsNonRoot Set Client containers' Security Context runAsNonRoot
  ## @param client.containerSecurityContext.readOnlyRootFilesystem Set Client containers' Security Context runAsNonRoot
  ## @param client.containerSecurityContext.allowPrivilegeEscalation Set Client container's privilege escalation
  ## @param client.containerSecurityContext.capabilities.drop Set Client container's Security Context runAsNonRoot
  ##
  containerSecurityContext:
    enabled: true
    runAsUser: 1001
    runAsGroup: 1001
    runAsNonRoot: true
    readOnlyRootFilesystem: true
    allowPrivilegeEscalation: false
    capabilities:
      drop: ["ALL"]

We're making them even more restricted than the security standard, setting runAsGroup or readOnlyRootFilesystem. Other examples include apisix, milvus or flux. Please let us know if these settings would be enough or we need to set extra settings in the security context.

[gcapizzi]

That looks good. I would consider adding seccompProfile to containerSecurityContext as well, as a convenient way to have everything in the same place.

[javsalgar]

Linking Jenkins to this issue

https://github.com/bitnami/charts/commit/86a5b1a768f74f7e9d36999bd84f8999616b7bcb

[bartwitkowski]

We're making them even more restricted than the security standard, setting runAsGroup or readOnlyRootFilesystem. Other examples include apisix, milvus or flux. Please let us know if these settings would be enough or we need to set extra settings in the security context.

Hey @javsalgar you wrote that Bitnami Helm charts are more restricted because of readOnlyRootFilesystem. So why this setting was changed to false with your PR in Rabbitmq-operator?

Previously for a long time this setting was readOnlyRootFilesystem=true

[javsalgar]

Hi!

This may due to a copy-paste error. Would you like to submit a PR restoring the value?

[bartwitkowski]

@javsalgar something like this PR ? :-)

[javsalgar]

Thank you!