Security context

In Kubernetes, a securityContext defines privilege and access control settings for a Pod or Container. You can set up it through the podTemplate section of an Elastic resource specification.

As of version 8.8.0, the Elasticsearch container and ECK managed sidecars and init containers are running with the following security context:

securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
    - ALL
  privileged: false
  readOnlyRootFilesystem: true
		

1. readOnlyRootFilesystem is only enabled if the elasticsearch-data directory is mounted in a volume.

The Elasticsearch process runs as a non-root user. For the process to write to the data volume, the volume must be writable for that user.

By default, ECK adds a Pod-level security context to Elasticsearch Pods. It sets fsGroup: 1000, which matches the group of the elasticsearch user in the Elasticsearch container image. Kubernetes then changes the group ownership of the volumes when it mounts them.

ECK doesn't add the default Pod security context in the following cases:

• The set-default-security-context operator flag is false.
• The flag is auto-detect, which is the default, and the operator detects that it runs on Red Hat OpenShift. OpenShift assigns fsGroup from the range allocated to the namespace. Don't set fsGroup yourself in this case, because OpenShift rejects other values unless the service account can use a security context constraint that allows any fsGroup.

For more information about the flag, refer to ECK configuration flags.

If ECK doesn't set the default security context and neither your platform nor your storage sets the ownership of the volume, Elasticsearch can fail to start with an error similar to failed to obtain node locks ... maybe these locations are not writable. The elastic-internal-init-filesystem init container doesn't fix this, because it runs as a non-root user by default and can't change the ownership of the data volume. In these cases, set fsGroup: 1000 explicitly in the podTemplate of your node sets:

spec:
  nodeSets:
  - name: default
    count: 3
    podTemplate:
      spec:
        securityContext:
          fsGroup: 1000
		

In versions of Elasticsearch before 8.0.0, the Elastisearch container is run as root and its entrypoint is responsible to run the Elasticsearch process with the elasticsearch user (defined with ID 1000). In the background, ECK uses an initContainer to make sure that the data volume is writable for the elasticsearch user.

To run the Elastisearch container as a non-root user, you need to configure the Elasticsearch manifest with an appropriate security context to make the data volume writable to the elasticsearch user by specifying the right group ID through the fsGroup.

Kubernetes recursively changes ownership and permissions for the contents of each volume to match the fsGroup specified in a Pod’s securityContext when that volume is mounted and makes all processes of the containers part of the supplementary group ID.

For example, if you force the Pod to run as user 1234, you need to set fsGroup accordingly to 1234:

apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: quickstart
spec:
  version: 9.5.7
spec:
  nodeSets:
  - name: default
    count: 3
    podTemplate:
      spec:
        securityContext:
          runAsUser: 1234
          fsGroup: 1234
		

1. Any containers in the Pod run all processes with user ID 1234.
2. All processes are also part of the supplementary group ID 1234, that owns the Pod volumes.