Secure communication with Elasticsearch
Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud. Availability This functionality is generally available and ready for production usage. Serverless interfaces and procedures might differ from classic Elastic Stack deployments. The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats. Availability This functionality is generally available and ready for production usage. Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.
Serverless
Generally available
Stack
Generally available
When sending data to a secured cluster through the elasticsearch output, Heartbeat can use any of the following authentication methods:
- Basic authentication credentials (username and password).
- Token-based API authentication.
- A client certificate.
Authentication is specified in the Heartbeat configuration file:
To use basic authentication, specify the
usernameandpasswordsettings underoutput.elasticsearch. For example:YAML output.elasticsearch: hosts: ["https://myEShost:9200"] username: "heartbeat_writer" password: "YOUR_PASSWORD"- This user needs the privileges required to publish events to Elasticsearch. To create a user like this, see Create a publishing user.
- This example shows a hard-coded password, but you should store sensitive values in the secrets keystore.
To use token-based API key authentication, specify the
api_keyunderoutput.elasticsearch. For example:YAML output.elasticsearch: hosts: ["https://myEShost:9200"] api_key: "ZCV7VnwBgnX0T19fN8Qe:KnR6yE41RrSowb0kQ0HWoA"- This API key must have the privileges required to publish events to Elasticsearch. To create an API key like this, see Grant access using API keys.
To use Public Key Infrastructure (PKI) certificates to authenticate users, specify the
certificateandkeysettings underoutput.elasticsearch. For example:YAML output.elasticsearch: hosts: ["https://myEShost:9200"] ssl.certificate: "/etc/pki/client/cert.pem" ssl.key: "/etc/pki/client/cert.key"- The path to the certificate for SSL client authentication
- The client certificate key
These settings assume that the distinguished name (DN) in the certificate is mapped to the appropriate roles in the
role_mapping.ymlfile on each node in the Elasticsearch cluster. For more information, see Using role mapping files.By default, Heartbeat uses the list of trusted certificate authorities (CA) from the operating system where Heartbeat is running. If the certificate authority that signed your node certificates is not in the host system’s trusted certificate authorities list, you need to add the path to the
.pemfile that contains your CA’s certificate to the Heartbeat configuration. This will configure Heartbeat to use a specific list of CA certificates instead of the default list from the OS.Here is an example configuration:
YAML output.elasticsearch: hosts: ["https://myEShost:9200"] ssl.certificate_authorities: - /etc/pki/my_root_ca.pem - /etc/pki/my_other_ca.pem ssl.certificate: "/etc/pki/client.pem" ssl.key: "/etc/pki/key.pem"- Specify the path to the local
.pemfile that contains your Certificate Authority’s certificate. This is needed if you use your own CA to sign your node certificates. - The path to the certificate for SSL client authentication
- The client certificate key
NoteFor any given connection, the SSL/TLS certificates must have a subject that matches the value specified for
hosts, or the SSL handshake fails. For example, if you specifyhosts: ["foobar:9200"], the certificate MUST includefoobarin the subject (CN=foobar) or as a subject alternative name (SAN). Make sure the hostname resolves to the correct IP address. If no DNS is available, then you can associate the IP address with your hostname in/etc/hosts(on Unix) orC:\Windows\System32\drivers\etc\hosts(on Windows).
More information on sending data to a secured cluster is available in the configuration reference: