Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

Feel free to contribute it - otherwise it will have to wait for someone to pick it up (marked it as good-first-issue since there are some clear examples it can be based on)

cc @nevcohen maybe you be intreated in fixing this one?

Actually, a good fix would be to just remove the hard coded runAsUser and fsGroup. Openshift by default will apply the restricted-v2 SCC policy, which doesn't allow this template to be deployed. Openshift will add those values.

Security context block would also be good if it can be removed entirely for other clusters that apply SCC rules.

Maybe a bool and condition for runAsUser and fsGroup that are omitted when openshift=true?

Hi @philthynz ,

I hope you're doing well.

I am working on adapting the Helm chart to support OpenShift compatibility, particularly in relation to runAsUser and fsGroup settings. Based on your suggestion, I plan to make the following changes:

Add an openshift flag: This flag will determine whether to adapt the security context for OpenShift.

Conditional Inclusion of securityContext: In the Helm chart templates, I will conditionally include or exclude the securityContext block based on the openshift flag and adaptSecurityContext setting.

If openshift=true: The securityContext block will be omitted, allowing OpenShift to apply its default security settings.
For other Kubernetes environments: The securityContext block will include runAsUser and fsGroup settings if they are specified.
I’d like to confirm if this approach aligns with your expectations and the best practices for handling OpenShift compatibility. Additionally, if there are any other considerations or adjustments you recommend, please let me know.

Thanks

Hi @deveshgoyal1000 ,

Thanks for jumping in. I am well thanks.

Yes your plan will work. I thought it was more simple to allow runAsUser and fsGroup values to be null. Openshift would accept that too. As an example:

securityContext: {
  runAsUser: 
  fsGroup:  
}

Blank values are accepted in restricted-v2.

But you're right. The underlying issue here is that the securityContexts block can't be fully omitted to allow Openshift to apply the default SCC config.

As a workaround we are using helm template and then a find and replace to make runAsUser and fsGroup blank.

Do you mind if I ask your time frame?

I can get this done 1-2 if but which approch should i do making runAsUser and fsGroup values to be null or Conditionally including or excluding the securityContext block based on this flag and the adaptSecurityContext setting. and updating
deployment templates with

{{- if and (eq .Values.global.compatibility.openshift.adaptSecurityContext "auto") (eq .Values.global.compatibility.openshift.openshift true) }}
securityContext: {}
{{- else }}
securityContext:
  runAsUser: {{ .Values.containerSecurityContext.runAsUser | default "" }}
  fsGroup: {{ .Values.podSecurityContext.fsGroup | default "" }}
{{- end }}

Hey @deveshgoyal1000 many thanks for this.

I would take the bitnami approach. Because users still may want to specify other attributes in the security context that Openshift would allow.

See here: https://blog.bitnami.com/2024/04/bitnami-helm-charts-are-now-more-secure.html?m=1

The runAsUser, runAsGroup, and fsGroup ahould be automatically removed. I.e, not set.

Hey @philthynz Thank you for pointing me to the Bitnami approach it looks great and aligns perfectly with our goals. I'll proceed with this method to ensure the Helm charts automatically remove runAsUser, runAsGroup, and fsGroup when deployed on OpenShift.
To ensure I’m on the right track, here’s the updated conditional logic that I’ll be applying :

{{- if and (eq .Values.global.compatibility.openshift.adaptSecurityContext "auto") (eq .Values.global.compatibility.openshift.enabled true) }}
containerSecurityContext: {}
podSecurityContext: {}
{{- else }}
containerSecurityContext:
  runAsUser: {{ .Values.containerSecurityContext.runAsUser | default "" }}
  runAsGroup: {{ .Values.containerSecurityContext.runAsGroup | default "" }}
podSecurityContext:
  fsGroup: {{ .Values.podSecurityContext.fsGroup | default "" }}
{{- end }}

This approach separates the containerSecurityContext and podSecurityContext, ensuring that OpenShift-specific settings are handled correctly, while also allowing other Kubernetes environments to use the specified values.

Please let me know if this aligns with your expectations or if there are any further adjustments needed.
Thanks!

Yea blank values will work. I've tested that. Many thanks.

Oh, that's nice! Thanks for confirming.

Hello, I saw this conversation, and I saw that now you can go and configure the uids and gid to "" in most places I have looked at. For example at general, statsd and redis. So maybe the only thing we need is to add to the docs?

Hi @deveshgoyal1000 , Do we have a PR in progress for this? We use openshift and are looking forward to these changes being added in 🙂