Beats SSL Cert & Key exposure

In every *beat.yml file we define the output destination, In my case we use logstash for logs to be ingested from beats. Along the beats config.yml file we supply the logstash and kibana ssl cert and it's key.

output.logstash:
  hosts: ["<logstash-host-address>:5042"]
  bulk_max_size: 1024
  ssl.certificate_authorities: "/etc/filebeat/certs/ca.crt"
  ssl.certificate: "/etc/filebeat/certs/<logstash>.crt"
  ssl.key: "/etc/filebeat/certs/<logstash>.key"
  loadbalance: true


setup.kibana:
  host: "https://<kibana-host-address>:5601"
  username: "elastic"
  password: "${ES_PWD}"
  ssl.certificate_authorities: "/etc/filebeat/certs/ca.crt"
  ssl.certificate: "/etc/filebeat/certs/<kibana>.crt"
  ssl.key: "/etc/filebeat/certs/<kibana>.key"

Question: How safe is it to place (and/or) why do we need both the cert and key on the beats agent considering the compromise of our corporate cert & key which may lead to impersonation
[As my base understanding on certificate functioning: we should only supply the CA-Root Cert for trusting host(logstash.kibana) cert]

Can anyone please help me in understanding the usecase of supplying these two entities and also I would request a secure way of using these (cert & key) if it's really needed on beats agents

The ssl.certificate and ssl.key are used to specify client certificates for the SSL connection.
Client certificates (sometimes known as mutual TLS) are used to authenticate the client to the server.

You should not specify the logstash or kibana certificate and key in your *beat.yml. In typical configurations you do not need to specify these at all. It is very rare for Kibana to use client certificates. It is a little more common in the case Logstash (because Logstash doesn't offer the same username/password authentication option that Kibana has), but is not the most common setup.

I expect in your case that you can just remove these lines from your config.

If it turns out that you do need client certificates, then you should not use the logstash/kibana ones, and should instead get a new certificate that is specifically for your beats.

If you can point out which documentation lead you to believe that this was the configuration you need, then please let us know and so we can see if there is a way to make it more clear.

Thank You @TimV for your valuable response.
On the logstash-pipeline, I've removed the forced_peer config and changed to peer.
On beats, I'm just passing the root ca-cert and connection is well established.

The article which I referred before which stated to use cert & key was : configuring-ssl-logstash

Question: Now I'm just using root ca.cert on beats. Is it safe to use the same auth-method on production system without leading to any other security compromise ?

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