1.1.0 release highlights
edit1.1.0 release highlights
editNew and notable
editNew 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.
Remote cluster support
editEstablishing 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.
Declarative user management
editFile realm users and roles are now configurable using Kubernetes secrets. This enables consistent and auditable user management practices and GitOps use cases.
Enhanced validation
editValidation 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.
Enforce RBAC on associations
editAccess 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.
Filebeat discovery hints
editECK resources have the correct discovery hints added by default to facilitate Filebeat discovery.
Default container registry for air-gapped installations
editThe 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.
Breaking changes
editRemoval of operator roles
editThe 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 port name change
editContainer 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.
Readiness probe change for Kibana and APM Server
editDefault 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.15.2 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.15.2 count: 1 elasticsearchRef: name: quickstart podTemplate: spec: containers: - name: apm-server readinessProbe: httpGet: scheme: HTTPS path: "/" port: 8200
Security Advisory
editECK 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.