Skip to content

ECK Operator

Ownership and configuration

This package wraps Elastic’s ECK operator chart and adds Big Bang integration for Iron Bank images, security contexts, Istio, network policies, operator metrics, OpenShift, and license Secrets. The operator installs Elastic Custom Resource Definitions (CRDs) and reconciles workload custom resources. The Elasticsearch/Kibana package owns those workload resources, their storage, ingress, and OIDC configuration; they are not operator configuration.

The umbrella owns package source pins, automatic enablement, namespaces, pull Secrets, values mapping, and Flux dependency ordering. It installs the operator release in eck-operator when either ECK Operator or Elasticsearch/Kibana is enabled; the workload release depends on the operator. Disabling only the operator toggle does not suppress it while Elasticsearch/Kibana remains enabled.

For the canonical umbrella interface, opt in to packageConfiguration.version: v1 and use packages.eckOperator. The legacy entry point is eckOperator. For example, to enable the operator without configuring a managed workload:

packageConfiguration:
  version: v1
packages:
  eckOperator:
    enabled: true

Wrapper options go under packages.eckOperator.values; upstream operator options go under the passthrough parent packages.eckOperator.values.upstream. For direct package Helm use, omit the umbrella nesting and use upstream as the parent. Use the ECK 3.5.0 upstream values for the complete upstream configuration surface and package values for Big Bang overrides. Match upstream references to the dependency version in Chart.lock. Scheduling the operator is separate from scheduling ECK-managed workloads; see Operator scheduling.

CRD ownership and upgrades

The bundled upstream dependency installs CRDs by default. CRDs are cluster-scoped even though Elastic workload custom resources are namespaced. Coordinate operator versions and CRD ownership before sharing a cluster with another ECK installation. The bundled CRD templates carry helm.sh/resource-policy: keep; this does not make manual CRD deletion safe or replace backups. Removing CRDs can remove managed resources. See Elastic’s Helm installation guidance and operator upgrade guidance before changing CRD ownership or upgrading.

upgradeCrds.enabled is a disabled-by-default legacy migration hook, not a routine upgrade option. When enabled, it renders a Helm pre-upgrade Job and cluster-wide CRD RBAC, including delete permission. The Job command checks for CRDs labeled with the release instance whose version label contains 1.6.0, then attempts replacement only if its mounted CRD file exists. That check is narrower than a general 1.6.x upgrade and does not establish that this hook works with today’s bundled archive. Do not enable or run it manually without maintainer review of the specific legacy migration and rendered CRD payload. Normal upgrades should follow upstream guidance and the maintainer-authored development and maintenance runbook.

Webhook and service mesh

The validating webhook Service listens on 443 and targets the operator’s 9443 endpoint. Kubernetes API-server calls must reach it without requiring an Istio client sidecar. In mesh-enabled umbrella deployments, the operator pod annotations exclude inbound 9443 from sidecar interception. The wrapper also renders an operator-selected PeerAuthentication exception when bb-common.istio.enabled is true and bb-common.istio.mtls.mode is STRICT, setting port 9443 to PERMISSIVE while retaining the configured workload mTLS mode. This exception does not disable the webhook’s own TLS.

Preserve the exclusion and port-level exception when overriding operator pod annotations or mesh settings. Standalone package deployments must arrange mesh enrollment and annotations themselves; rendering Istio resources does not inject a sidecar. See Istio integration for shared-library references. Ambient and sidecar modes require separate validation of webhook reachability and operator reconciliation; a local Helm render is not deployed evidence.

Operator metrics and network policies

The package enables the operator metrics listener on 8080, but its wrapper serviceMonitor.enabled is false by default. Enabling it creates a metrics Service and ServiceMonitor; the target port comes from the upstream operator configuration. The umbrella enables the monitor when its metric-scraping helper is active and supplies Istio certificate paths when sidecar STRICT mTLS scraping applies. Prometheus must have the matching certificates mounted and be able to discover the monitor.

The wrapper’s default scrape scheme is https. That setting alone does not enable upstream secure metrics or install mesh transport. For standalone use, align the listener, scrape scheme, TLS/authentication, and Prometheus discovery before enabling the monitor. Do not confuse the wrapper serviceMonitor with the separate upstream monitoring options beneath the passthrough parent.

Network policies use bb-common. Package-specific rules include operator egress to Elasticsearch on 9200, Kibana on 5601, and the Kubernetes API; the workload selectors cover matching Elastic pods across namespaces. Metrics ingress targets the operator on 8080 from monitoring Prometheus. The umbrella supplies the global kubeAPI definition, monitoring and Tempo selections, and common mesh/network defaults. If you change ports, labels, destinations, or watched namespaces, review the corresponding policies rather than assuming they adapt automatically. See Network policies for the shared policy contract.

OpenShift integration

openshift: true renders a ClusterRoleBinding for nonroot-v2 SCC access to the service-account group for the entire release namespace, not just the operator ServiceAccount. When both openshift and bb-common.istio.enabled are true, the wrapper renders a NetworkAttachmentDefinition named istio-cni. These resources do not install OpenShift SCCs or Istio CNI. Review namespace occupants and cluster prerequisites before enabling them. The umbrella maps its global OpenShift input to this package.

Licensing

Elastic is the authority for license tiers, entitlements, trial eligibility, expiration, and renewal. Consult Manage your license in ECK, not a copied feature matrix.

The wrapper renders license Secrets in the operator release namespace using pre-install,pre-upgrade hooks. A nonempty license.keyJSON creates elastic-license with license.k8s.elastic.co/scope: operator. Otherwise, license.trial: true creates elastic-trial-license with the enterprise-trial label and EULA acceptance annotation. A key takes precedence over the trial flag. Neither path is enabled by package defaults. Trial activation constitutes EULA acceptance; obtain appropriate approval before enabling it.

For umbrella deployments, the supported input remains packages.elasticsearchKibana.license outside values (legacy: elasticsearchKibana.license). The umbrella forwards it into operator-generated license defaults. packages.eckOperator.values.license can override those defaults because package overlays are applied last. There is no requirement to relocate the input to packages.eckOperator.license.

Keep commercial license JSON in your approved encrypted-secret workflow, not examples, source control, logs, or rendered artifacts. The chart’s fixed-name hook Secret behavior is not a replacement for Elastic’s renewal procedure. Verify license status according to upstream guidance without printing the Secret.

Validation and further reading

helm lint chart is the repository’s read-only local chart check. It does not validate webhook calls, CRD lifecycle, license recognition, metrics scraping, or reconciliation. Package CI selects an ECK-managed Elasticsearch/Kibana workload for standard and ambient cases; actual clean-install and upgrade evidence belongs to that external disposable-cluster pipeline.