Problem
When Kibana runs standalone (elasticstack_full_stack: false, the default), the role configures no Elasticsearch connection — the whole elasticsearch.hosts / auth / TLS block in kibana.yml.j2 is gated by elasticstack_full_stack. As a result, kibana_elasticsearch_hosts has no effect and Kibana silently falls back to http://localhost:9200.
This blocks a common setup: Elasticsearch runs elsewhere (Elastic Cloud, corporate cluster, other tooling) and only Kibana is installed through this collection.
Kibana supports this natively — elasticsearch-certutil is not required, and any CA can be used. The beats role already exposes this pattern via beats_tls_*; Kibana does not.
Goal
Make the Elasticsearch connection configurable for standalone Kibana:
-
Connection + login
Write elasticsearch.hosts from kibana_elasticsearch_hosts, and allow the login credentials to be set via variables (username/password). The full-stack path reads the kibana_system password from initial_passwords on the CA host; that host does not exist standalone, so credentials must be user-provided.
-
Own CA / certificates
Allow Kibana to trust a user-provided CA for the Elasticsearch connection (corporate or public CA), instead of only the collection's certutil CA. This is optional: a publicly trusted CA works via the host's OS trust store; a CA only needs to be specified for a private/self-signed CA.
Safe defaults (non-breaking)
Everything defaults to today's behaviour: kibana_elasticsearch_hosts → http://localhost:9200, no TLS, no auth. Existing full-stack and standalone-localhost setups are unaffected — the new options are purely additive.
Notes
The elasticstack_variant == "elastic" check on the block is redundant for Kibana (there is no OSS Kibana).
Mutual TLS (Kibana presenting a client certificate) is tracked separately in #486 and builds on this.
Problem
When Kibana runs standalone (elasticstack_full_stack: false, the default), the role configures no Elasticsearch connection — the whole elasticsearch.hosts / auth / TLS block in kibana.yml.j2 is gated by elasticstack_full_stack. As a result, kibana_elasticsearch_hosts has no effect and Kibana silently falls back to http://localhost:9200.
This blocks a common setup: Elasticsearch runs elsewhere (Elastic Cloud, corporate cluster, other tooling) and only Kibana is installed through this collection.
Kibana supports this natively — elasticsearch-certutil is not required, and any CA can be used. The beats role already exposes this pattern via beats_tls_*; Kibana does not.
Goal
Make the Elasticsearch connection configurable for standalone Kibana:
Connection + login
Write elasticsearch.hosts from kibana_elasticsearch_hosts, and allow the login credentials to be set via variables (username/password). The full-stack path reads the kibana_system password from initial_passwords on the CA host; that host does not exist standalone, so credentials must be user-provided.
Own CA / certificates
Allow Kibana to trust a user-provided CA for the Elasticsearch connection (corporate or public CA), instead of only the collection's certutil CA. This is optional: a publicly trusted CA works via the host's OS trust store; a CA only needs to be specified for a private/self-signed CA.
Safe defaults (non-breaking)
Everything defaults to today's behaviour: kibana_elasticsearch_hosts → http://localhost:9200, no TLS, no auth. Existing full-stack and standalone-localhost setups are unaffected — the new options are purely additive.
Notes
The elasticstack_variant == "elastic" check on the block is redundant for Kibana (there is no OSS Kibana).
Mutual TLS (Kibana presenting a client certificate) is tracked separately in #486 and builds on this.