NETWAYS / NETWAYS/ansible-collection-elasticstack
[Feature]: Optionally support mutual TLS between Kibana and Elasticsearch
Nobody has claimed this yet.
- Dominant language
- Jinja
- Stars
- 14
- Forks
- 11
- Avg merge
- 1d 47m
- Merged PRs (30d)
- 6
Description
Kibana currently authenticates to Elasticsearch with username/password over standard TLS
(the Elastic default). The role already generates a client certificate (<host>-kibana.p12)
via elasticsearch-certutil and copies it to /etc/kibana/certs, but it is never
referenced in kibana.yml — so it is unused today.
Add opt-in mutual TLS (default: disabled):
- New toggle (e.g.
kibana_elasticsearch_mtls, defaultfalse). - When enabled, Kibana presents a client certificate. Support two sources:
- Collection-generated (default): use the already-generated
<host>-kibana.p12
(signed by the shared CA). Gives today's unused certificate a purpose and fits the
standard setup where Elasticsearch trusts the shared CA. - Bring your own: let the user point to their own client certificate/key
(e.g.kibana_elasticsearch_cert/kibana_elasticsearch_key, or a keystore). Needed
when Elasticsearch trusts a corporate/external CA instead of the collection's — the
client cert must then be signed by that CA, so the generated one would be rejected. - Wire the chosen source into
kibana.yml
(elasticsearch.ssl.certificate/keyorelasticsearch.ssl.keystore.path).
- Collection-generated (default): use the already-generated
- Document that Elasticsearch must request client certs
(xpack.security.http.ssl.client_authentication: optional, typically with a PKI realm —
Elastic recommendsoptional, notrequired). - When disabled (default): do not generate the client certificate — removing today's
unusedkibana.p12.
Default behaviour stays credential-based, so this is additive and non-breaking. The
bring-your-own path pairs with the own-CA trust from #483 (Kibana verifying Elasticsearch)
for a full corporate-PKI setup. Depends on #483.
Part of #536 (collection-wide opt-in mTLS umbrella).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the role logic that invokes elasticsearch-certutil, copies the Kibana certificate into /etc/kibana/certs, and renders kibana.yml; also review dependency issue #483. Done means the default remains credential-based without generating kibana.p12, while opt-in collection-generated and bring-your-own certificate sources configure Kibana mTLS and document the required Elasticsearch client authentication settings.
Written by the indexing model from the issue text.
Assessment
- Domain
- infrastructure, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100