Securing Communication
editSecuring Communication
editTo secure the communication between Topbeat and Elasticsearch, you can use HTTPS and basic authentication. Here is a sample configuration:
elasticsearch: username: topbeat password: verysecret protocol: https hosts: ["elasticsearch.example.com:9200"]
The username to use for authenticating to Elasticsearch. |
|
The password to use for authenticating to Elasticsearch. |
|
This setting enables the HTTPS protocol. |
|
The IP and port of the Elasticsearch nodes. |
Elasticsearch doesn’t have built-in basic authentication, but you can achieve it either by using a web proxy or by using the Shield commercial plugin.
Topbeat verifies the validity of the server certificates and only accepts trusted certificates. Creating a correct SSL/TLS infrastructure is outside the scope of this document, but a good guide to follow is the Setting Up a Certificate Authority appendix from the Shield guide.
By default Topbeat uses the list of trusted certificate authorities from the operating system where Topbeat is running. You can configure a Beat to use a specific list of CA certificates instead of the list from the OS. Here is an example:
elasticsearch: username: topbeat password: verysecret protocol: https hosts: ["elasticsearch.example.com:9200"] tls: certificate_authorities: - /etc/pki/my_root_ca.pem - /etc/pki/my_other_ca.pem
For any given connection, the SSL/TLS certificates must have a subject
that matches the value specified for hosts
, or the TLS handshake fails.
For example, if you specify hosts: ["foobar:9200"]
, the certificate MUST
include foobar
in 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) or C:\Windows\System32\drivers\etc\hosts
(on Windows).