Elastic Cloud on Kubernetes known issues

Known issues are significant defects or limitations that may impact your implementation. These issues are actively being worked on and will be addressed in a future release. Review the Elastic Cloud on Kubernetes known issues to help you make informed decisions, such as upgrading to a new version.

3.4.1

In ECK 3.4.x, the Logstash controller always injects seccompProfile: RuntimeDefault and fsGroup: 1000 into the pod security context, ignoring the --set-default-security-context=auto-detect flag. On OpenShift, this flag should suppress the injection — as it does for Elasticsearch, Kibana, and APM Server. As a result, clusters using a non-default SCC such as anyuid, which forbids explicit seccomp settings, reject Logstash pods at admission after upgrading.

For more information, check this Issue #9550.

Workaround

This workaround applies only to namespaces using an anyuid-style SCC (RunAsAny fsGroup, seccomp forbidden) that do not enforce restricted Pod Security Admission. Check your namespace's labels first:

		kubectl get namespace <your-namespace> -o jsonpath='{.metadata.labels}'

# or on OpenShift:
oc get namespace <your-namespace> -o jsonpath='{.metadata.labels}'

If the output contains pod-security.kubernetes.io/enforce: restricted, do not apply this workaround: restricted PSA requires seccompProfile and expects fsGroup within the namespace's allocated supplemental-groups range, not a fixed 1000.

Otherwise, set the security context on the Logstash resource so ECK skips its own injection:

		spec:
  podTemplate:
    spec:
      securityContext:
        fsGroup: 1000
        # seccompProfile intentionally omitted — not permitted by anyuid SCC
		
	

Important

Apply this override to existing Logstash resources before upgrading to ECK 3.4. If you are already running ECK 3.4 and the pods are in the SCC rejection loop, delete the Logstash resource and re-create it with the override described in this workaround.

You can remove this override after upgrading to ECK 3.5.0 or later (once available), which fixes #9550.

3.4.0

In ECK 3.4.x, the Logstash controller unconditionally injects seccompProfile: RuntimeDefault and fsGroup: 1000 into the pod security context, ignoring the --set-default-security-context=auto-detect operator flag. On OpenShift, this flag should suppress the injection, as it does for all other ECK-managed workloads (Elasticsearch, Kibana, APM Server). Clusters using a non-default SCC such as anyuid — which does not permit explicit seccomp configuration — will see Logstash pods rejected at admission after upgrading.

For more information, check this Issue #9550.

Workaround

This workaround applies only to namespaces governed by an anyuid-style SCC (RunAsAny fsGroup, seccomp forbidden) that are not also enforcing restricted Pod Security Admission.

To check whether your namespace enforces restricted PSA, run:

		kubectl get namespace <your-namespace> -o jsonpath='{.metadata.labels}'

# or on OpenShift:
oc get namespace <your-namespace> -o jsonpath='{.metadata.labels}'

If you see pod-security.kubernetes.io/enforce: restricted, do not use this workaround — in restricted-PSA namespaces, seccompProfile is required and must not be omitted, and fsGroup must fall within the namespace's allocated supplemental-groups range rather than a fixed value like 1000.

For namespaces using anyuid-style SCC without restricted PSA enforcement, override the Logstash pod security context as follows to prevent ECK from injecting its defaults:

		spec:
  podTemplate:
    spec:
      securityContext:
        fsGroup: 1000
        # seccompProfile intentionally omitted — not permitted by anyuid SCC
		
	

Important

You can remove this override after upgrading to ECK 3.5.0 or later (once available), which fixes #9550.

3.3.2

3.3.1

3.3.0

3.2.0

Elastic Agent fails to start with "cipher: message authentication failed" after re-upgrading to ECK 3.2.0, the CONFIG_PATH for Elastic Agent in Fleet mode was changed to align with the STATE_PATH (tracking Issue #8819).

If you upgrade to 3.2.0, downgrade to a previous version (like 3.1.0), and then upgrade back to 3.2.0, the Elastic Agent Pods may fail to start. This occurs because the agent, using the new CONFIG_PATH, is unable to decrypt the existing state files encrypted with keys from the old path.

You will see errors in the agent logs similar to one of the following:

Error: fail to read state store '/usr/share/elastic-agent/state/data/state.enc': failed migrating YAML store JSON store: could not parse YAML fail to decode bytes: cipher: message authentication failed

Error: fail to read action store '/usr/share/elastic-agent/state/data/action_store.yml': yaml: input error: fail to decode bytes: cipher: message authentication failed

For more information, check PR #8856.

Workaround

To work around this issue, you must force the Agent to re-enroll. Add the FLEET_FORCE=true environment variable to your Agent's podTemplate specification. This will cause the agent to start fresh and re-enroll with Fleet.

This environment variable can be removed once the Agent has successfully started and re-enrolled.

		apiVersion: agent.k8s.elastic.co/v1alpha1
kind: Agent
metadata:
  name: eck-agent
spec:
  # ... other agent specs
  podTemplate:
    spec:
      containers:
        - name: agent
          env:
            - name: FLEET_FORCE
              value: "true"
		
	

Your Agent resource name

3.1.0

3.0.0

On May 19th 2025, it was discovered that the Elastic Maps Server container image in versions 7.17.28, 8.18.0, 8.18.1, 9.0.0 and 9.0.1 does not start on OpenShift Container Platform with the following error: container create failed: open executable: Operation not permitted.

For more information, check Issue #8655.

Workaround

To workaround the issue override the container command for Elastic Maps Server:

		apiVersion: maps.k8s.elastic.co/v1alpha1
kind: ElasticMapsServer
metadata:
  name: ems-sample
spec:
  version: 9.0.0
  count: 1
  podTemplate:
    spec:
      containers:
        - name: maps
          command: [ /bin/sh, -c, "node app/index.js"]
		
	