Use non-root containers

Ensuring that a container is able to perform only a very limited set of operations is vital for production deployments. This is possible thanks to the use of non-root containers, which are executed by a user different from root. Although creating a non-root container is a bit more complex than a root container (especially regarding filesystem permissions), it is absolutely worth it. Also, in environments like Openshift, using non-root containers is mandatory.

In order to make your Helm chart work with non-root containers, add the securityContext section to your yaml files.

This is what we do, for instance, in the Bitnami Elasticsearch Helm chart. This chart deploys several Elasticsearch StatefulSets and Deployments (data, ingestion, coordinating and master nodes), all of them with non-root containers. If we check the master node StatefulSet, we see the following:

spec:
  {{- if .Values.securityContext.enabled }}
  securityContext:
    fsGroup: {{ .Values.securityContext.fsGroup }}
  {{- end }}

The snippet above changes the permissions of the mounted volumes, so the container user can access them for read/write operations. In addition to this, inside the container definition, we see another securityContext block:

{{- if .Values.securityContext.enabled }}
securityContext:
  runAsUser: {{ .Values.securityContext.runAsUser }}
{{- end }}

In this part we specify the user running the container. In the values.yaml file, we set the default values for these parameters:

## Pod Security Context
## ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
##
securityContext:
  enabled: true
  fsGroup: 1001
  runAsUser: 1001

With these changes, the chart will work as non-root in platforms like GKE, Minikube or Openshift.

Next steps: Implement best practices to create production-ready Helm charts

Learn more about the best practices to create production-ready Helm charts in this tutorial.