[bitnami/elasticsearch] unable to deploy elasticsearch on openshift

[toobster]

Name and Version

bitnami/elasticsearch 21.0.2/3

What architecture are you using?

amd64

What steps will reproduce the bug?

1. deploy elasticsearch with the default values on an openshift cluster (i am using version: 4.12)

Are you using any custom parameters or values?

No

What is the expected behavior?

with this version of the helm chart it should automatically detect an openshift environment and adapt the security context and successfully deploy an elasticsearch cluster.

What do you see instead?

apparently it does not apply for initConainers as i am getting following errors:

create Pod mdm-elasticsearch-coordinating-0 in StatefulSet mdm-elasticsearch-coordinating failed error: pods "mdm-elasticsearch-coordinating-0" is forbidden: unable to validate against any security context constraint: [provider "trident-controller": Forbidden: not usable by user or serviceaccount, provider "anyuid": Forbidden: not usable by user or serviceaccount, provider restricted-v2: .initContainers[0].runAsUser: Invalid value: 0: must be in the ranges: [1000940000, 1000949999], provider restricted-v2: .initContainers[0].privileged: Invalid value: true: Privileged containers are not allowed, provider restricted-v2: .initContainers[1].runAsUser: Invalid value: 1001: must be in the ranges: [1000940000, 1000949999], provider restricted-v2: .initContainers[1].seLinuxOptions.level: Invalid value: "": must be s0:c31,c5, provider restricted: .initContainers[0].runAsUser: Invalid value: 0: must be in the ranges: [1000940000, 1000949999], provider restricted: .initContainers[0].privileged: Invalid value: true: Privileged containers are not allowed, provider restricted: .initContainers[1].runAsUser: Invalid value: 1001: must be in the ranges: [1000940000, 1000949999], provider restricted: .initContainers[1].seLinuxOptions.level: Invalid value: "": must be s0:c31,c5, pod.metadata.annotations[container.seccomp.security.alpha.kubernetes.io/copy-default-plugins]: Forbidden: seccomp may not be set, pod.metadata.annotations[container.seccomp.security.alpha.kubernetes.io/elasticsearch]: Forbidden: seccomp may not be set, provider "nonroot-v2": Forbidden: not usable by user or serviceaccount, provider "nonroot": Forbidden: not usable by user or serviceaccount, provider "rsync-anyuid": Forbidden: not usable by user or serviceaccount, provider "k10-scc": Forbidden: not usable by user or serviceaccount, provider "hostmount-anyuid": Forbidden: not usable by user or serviceaccount, provider "elasticsearch-scc": Forbidden: not usable by user or serviceaccount, provider "logging-scc": Forbidden: not usable by user or serviceaccount, provider "machine-api-termination-handler": Forbidden: not usable by user or serviceaccount, provider "k10-prometheus-server": Forbidden: not usable by user or serviceaccount, provider "k10-grafana": Forbidden: not usable by user or serviceaccount, provider "hostnetwork-v2": Forbidden: not usable by user or serviceaccount, provider "hostnetwork": Forbidden: not usable by user or serviceaccount, provider "hostaccess": Forbidden: not usable by user or serviceaccount, provider "mssql-persistent-kasten-scc": Forbidden: not usable by user or serviceaccount, provider "mssql-persistent-scc": Forbidden: not usable by user or serviceaccount, provider "trident-node-linux": Forbidden: not usable by user or serviceaccount, provider "node-exporter": Forbidden: not usable by user or serviceaccount, provider "privileged": Forbidden: not usable by user or serviceaccount, provider "privileged-etcd-backup": Forbidden: not usable by user or serviceaccount, provider "velero-privileged": Forbidden: not usable by user or serviceaccount]

[toobster]

workaround for the time beeing: set following values manually...

  sysctlImage.enabled: false

  coordinating.containerSecurityContext.enabled: false
  master.containerSecurityContext.enabled: false
  data.containerSecurityContext.enabled: false
  ingest.containerSecurityContext.enabled: false

[javsalgar]

Hi,

In principle, disabling the sysctlImage (which requires privileges) should be enough, not being necessary to disable the containerSecurityContext. Could you check it?

[toobster]

hi,
Yes i first tried it that way.
As far as I unterstand it there are other initContainers which miss the function to check for the openshift compatibility and andjust it accordingly.

for example this one in the coordinating statefulset:

 - name: copy-default-plugins
          image: {{ include "elasticsearch.image" . }}
          imagePullPolicy: {{ .Values.image.pullPolicy | quote }}
          {{- if .Values.coordinating.containerSecurityContext.enabled }}
          securityContext: {{- omit .Values.coordinating.containerSecurityContext "enabled" | toYaml | nindent 12 }}
          {{- end }}

[javsalgar]

Hi,

Indeed we missed that one. instead of

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

it should be

          {{- if .Values.coordinating.containerSecurityContext.enabled }}
          securityContext: {{- include "common.compatibility.renderSecurityContext" (dict "secContext" .Values.coordinating.containerSecurityContext "context" $) | nindent 12 }}
          {{- end }}

As you spotted the issue, would you like to submit a PR fixing the issue?

[toobster]

hey,

yes i will try to that soonish, thanks.

[toobster]

sorry, had initial trouble with signing the commit correctly and made a little mess in the first pull request. i hope you didn't get flooded by notifications... the second PR should be fine.

[carrodher]

Thank you for opening this issue and submitting the associated Pull Request. Our team will review and provide feedback. Once the PR is merged, the issue will automatically close.

Your contribution is greatly appreciated!