Warum benötigt Dateibeat nur cert und metricbeat brauchen Schlüssel, ca und cert?

Question

Ich bin ziemlich neu in der gesamten ELK-Stack, und ich habe es nur geschafft, beide Dateibeats und metricbeat einzurichten, um eine Verbindung zu einem Remote-ELK-Stack. Alle v6.0.0-rc1

Die SSL-Konfiguration hat mich ein wenig verwirrt, und ich bin mit der Frage: Warum benötigt Dateibeat nur Cert und Metricbeat brauchen Schlüssel, ca und 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" 

Answer 1

TLS/SSL verwendet eine Public-Key-Infrastruktur. Der Dienst, der authentifiziert werden muss, benötigt den öffentlichen und den privaten Schlüssel. Der andere Endpunkt (Validierung des Dienstes) benötigt nur den öffentlichen Schlüssel (oder besser nur das CA-Zertifikat - öffentlicher Schlüssel). Wenn Sie TLS/SSL standardmäßig verwenden, wird nur der Server authentifiziert, mit dem sich ein Client verbindet. In diesem Szenario sind Beats der Client und Logstash der Server.

Zusätzlich kann der Server den Client zur Authentifizierung auffordern (mit einem Zertifikat). Dieser Modus wird Client-Authentifizierung genannt und muss explizit auf dem Server aktiviert werden (Logstash). Wenn client-auth aktiviert ist, benötigt der Client außerdem ein Zertifikat und einen privaten Schlüssel. + Der Server benötigt das Zertifikat (oder CAs-Zertifikat), um den Client zu überprüfen/zu authentifizieren.

Wie auch immer, wenn Client-Auth verwendet wird, sollte jeder Client sein eigenes Client-Zertifikat mit passendem IP/Domänennamen haben. Plus Logstash sollte nur das öffentliche Zertifikat der Zertifizierungsstelle zur Überprüfung haben. Dies läuft auf eine ordnungsgemäße CA-Infrastruktur hinaus.

NIEMALS den privaten Schlüssel eines Endpunkts/Rechners mit einem anderen Rechner teilen.

Ist es eine schlechte Übung, den privaten Schlüssel an jeden Metrikschlag-Agenten zu verteilen?

In der Tat ist es.

Sollte dieser private Schlüssel ein Passwort haben?

Wenn möglich ja (wie private Schlüssel verschlüsselt werden sollen), aber dies höchstwahrscheinlichen Zugang zu verschleiern, wie somewhere the passphrase muss konfiguriert werden, so dass der Schlüssel verwendet werden kann. Dennoch kann die Verschlüsselung des Schlüssels den Schaden etwas reduzieren, wenn der Schlüssel gestohlen wird.

ohne Client-Authentifizierung die Beats Config sollte (mindestens) wie:

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

Mit Client-Authentifizierung die Beats config (mindestens) sein sollte wie:

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: ...