Why does filebeat only need cert and metricbeat need key, ca and cert? [RESOLVED]

Elastic Stack Beats
1

I am quite new to the whole ELK stack, and i just managed to set up both filebeat and metricbeat to connect to a remote ELK stack. All v6.0.0-rc1

The SSL setup got me a bit confused, and I am left with the question:
Why does filebeat only need cert and metricbeat need key, ca and cert?

filebeat.yml

ssl:
  certificate_authorities:
    - /host/certs/logstash-beats.crt

metricbeat.yml:

output.logstash:
    hosts: ["host.url:5044"] 
    ssl.certificate_authorities: ["/host/certs/reporter-ca.crt"]
    ssl.certificate: "/host/certs/reporter.crt"
    ssl.key: "/host/certs/reporter-private.key"
1 Like
2

Good question! And it raises the further questions:

  • Is it bad practice to distribute the private key to each metricbeat agent?
  • Should that private key have a password?
3

Yeah...
I would ask: is it "bad design" rather than "bad practice", because I couldn't get metricbeat to function without the private key.
Is there a way?

And if there was a password, what would be a reasonable way to use it?

4

Where do you have the beats configuration from?

TLS/SSL uses a public-key infrastructure. The service that needs to be authenticated requires the public and the private key. The other endpoint (validating the service) only requires the public key (or even better only the CA certificate - public key). When using TLS/SSL by default only the 'server' a client connects to will be authenticated. In this scenario beats are the client and Logstash is the server.

In addition the server can request the client to authenticate itself (using a certificate). This modus is called client-authentication and must be explicitly enabled in the server (Logstash). With client-auth enabled, the client also requires a certificate and a private key + the server requires the certificate (or CAs certificate) in order to verify/authenticate the client.

Anyways, when using client-auth, each client should have it's own client certificate with matching IP/Domain name. Plus Logstash should only have the CAs public certificate for verification. This boils down to having a proper CA infrastructure.

NEVER share the private key of an endpoint/machine with another machine.

Is it bad practice to distribute the private key to each metricbeat agent?

Indeed it is.

Should that private key have a password?

If possible yes (as private key should be encrypted), but this most likely obfuscate access, as somewhere the passphrase must be configured so the key can be used. Still, encrypting the key can somewhat reduce damage if the key gets stolen.

Without client authentication the beats config should be (at least) like:

output.logstash:
    hosts: ["host.url:5044"] 
    ssl.certificate_authorities:
    - /host/certs/logstash-beats.crt

With client authentication the beats config should be (at least) like:

output.logstash:
    hosts: ["host.url:5044"] 
    ssl.certificate_authorities:
    - /host/certs/logstash-beats.crt
    ssl.certificate: "/host/certs/reporter.crt"
    ssl.key: "/host/certs/reporter-private.key"
    ssl.key_passphrase: ...
1 Like
5

Thanks for the thorough explanation!

6

@steffens, I cross posted this at stack exchange, do you also have an account over there? Would be great if you post your precise answer there as well...

7

Sure, I added my answer to stackexchange. While stackX is an awesome platform in itself, I normally don't use it to discuss any beats issues. Beats issues often need more detailed discussions and questionaries, which the discuss forum is much better suited for.

8

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.