1.1.0 release highlights

New and notable changes in version 1.1.0 of Elastic Cloud on Kubernetes. See Elastic Cloud on Kubernetes version 1.1.0 for the full list of changes.

Establishing uni-directional connections from ECK-managed Elasticsearch clusters to other Elasticsearch clusters for cross-cluster replication and cross-cluster search purposes is now easy to achieve through a few additions to the YAML manifest. This feature is available for all managed clusters running a supported version of Elasticsearch with an Enterprise or Enterprise trial licence.

File realm users and roles are now configurable using Kubernetes secrets. This enables consistent and auditable user management practices and GitOps use cases.

Validation has been extended to more ECK resource types to catch invalid configurations during admission. Enabling the validating webhook will extend the capabilities of ECK to catch most common configuration issues during update operations as well.

Access control policies can be enforced on cross-namespace Elasticsearch associations created by Kibana and APM Server instances. This feature is disabled by default to avoid breaking existing deployments. See Restrict cross-namespace resource associations for more information.

ECK resources have the correct discovery hints added by default to facilitate Filebeat discovery.

The default container registry used by the operator can be configured to ease deployments in air-gapped environments. When the container registry is correctly configured, users no longer need to specify the container image field in their manifests.

The concept of global and namespace operator roles no longer exists, and as such, the --operator-roles flag has been removed. Instead, you can configure the operator to manage a pre-defined set of namespaces by passing a comma-separated list of namespaces to the --namespaces flag (default behaviour is to manage all namespaces). Instead of the webhook role, use the dedicated --enable-webhook flag to manage the webhook. See Configure ECK for more information about operator configuration flags.

Container ports of managed resources are now named according to the protocol (https for TLS enabled ports and http for TLS disabled ports). Previously they were named http regardless of the protocol being used. If you have any configurations that refer to the container ports by name (Ingress configurations, for example), review those to ensure that they use the correct name. One option may be to temporarily change to targeting the port number (e.g. 9200 for Elasticsearch), rather than the name, before updating ECK. Once the container port is updated to the new name, you can change to targeting the port name again.

Default readiness probes generated by the operator for Kibana and APM Server resources have changed from HTTP GET actions to exec actions. This is to accommodate environments where host-to-pod communication is restricted for security reasons. This change will affect ingress resources that are used to expose Kibana or APM Server, as some ingress controllers re-purpose the pod readiness probe as a health check. If you are unable to access Kibana or APM Server through the ingress after upgrading to ECK 1.1.0, override the readiness probe definitions as follows:

Kibana.

apiVersion: kibana.k8s.elastic.co/v1
kind: Kibana
metadata:
  name: quickstart
spec:
  version: 8.16.0
  count: 1
  elasticsearchRef:
    name: quickstart
  podTemplate:
    spec:
      containers:
        - name: kibana
          readinessProbe:
            httpGet:
              scheme: HTTPS
              path: "/login"
              port: 5601

APM Server.

apiVersion: apm.k8s.elastic.co/v1
kind: ApmServer
metadata:
  name: quickstart
spec:
  version: 8.16.0
  count: 1
  elasticsearchRef:
    name: quickstart
  podTemplate:
    spec:
      containers:
        - name: apm-server
          readinessProbe:
            httpGet:
              scheme: HTTPS
              path: "/"
              port: 8200

ECK versions prior to 1.1.0 generate Elasticsearch passwords using a weak random number generator. If an attacker is able to determine when an Elasticsearch cluster was deployed, they may be able to more easily brute force the Elasticsearch credentials generated by ECK. For existing clusters, we recommend users regenerate credentials following the steps detailed here. Resources created by ECK 1.1.0 do not require any action.