NETWAYS / NETWAYS/ansible-collection-elasticstack

[Feature]: Optionally support mutual TLS between Kibana and Elasticsearch

Open
#486 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

component:elasticsearch component:kibana feature
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, default false).
  • 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/key or elasticsearch.ssl.keystore.path).
  • Document that Elasticsearch must request client certs
    (xpack.security.http.ssl.client_authentication: optional, typically with a PKI realm —
    Elastic recommends optional, not required).
  • When disabled (default): do not generate the client certificate — removing today's
    unused kibana.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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.