2017-10-17 5 views
0

Je suis assez nouveau dans la pile ELK, et j'ai juste réussi à configurer à la fois filebeat et metricbeat pour se connecter à une pile ELK distante. Tous les v6.0.0-rc1Pourquoi filebeat n'a besoin que de cert et metricbeat besoin de clé, ca et cert?

La configuration SSL m'a un peu confus, et il me reste la question: Pourquoi filebeat n'a besoin que de cert et metricbeat besoin de clé, ca et 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" 
+0

Je suppose que, filebeat a configuration de certification déjà. https://www.elastic.co/guide/en/beats/filebeat/current/configuration-output-ssl.html Pourriez-vous avoir raté quelque chose? – hkulekci

+0

@steffens a donné une réponse assez profonde: https://discuss.elastic.co/t/why-does-filebeat-only-need-cert-and-metricbeat-need-key-ca-and-cert/104214/4 – gotjosh

Répondre

1

TLS/SSL utilise une infrastructure à clé publique. Le service qui doit être authentifié requiert les clés publique et privée. L'autre point de terminaison (validation du service) ne nécessite que la clé publique (ou mieux encore uniquement le certificat CA - clé publique). Lors de l'utilisation de TLS/SSL par défaut, seul le 'serveur' auquel un client se connecte sera authentifié. Dans ce scénario, les battements sont le client et Logstash est le serveur.

En outre, le serveur peut demander au client de s'authentifier (à l'aide d'un certificat). Ce modus est appelé authentification client et doit être explicitement activé dans le serveur (Logstash). Avec client-auth activé, le client nécessite également un certificat et une clé privée + le serveur nécessite le certificat (ou certificat CAs) afin de vérifier/authentifier le client.

Quoi qu'il en soit, lorsque vous utilisez client-auth, chaque client doit avoir son propre certificat client avec un nom IP/domaine correspondant. Plus Logstash ne doit avoir que le certificat public CA pour vérification. Cela revient à avoir une infrastructure CA appropriée. Ne partagez JAMAIS la clé privée d'un terminal/machine avec une autre machine.

Est-ce une mauvaise pratique de distribuer la clé privée à chaque agent de métrique?

En effet, c'est.

Cette clé privée doit-elle avoir un mot de passe?

Si possible oui (comme clé privée doit être chiffré), mais le plus probable obscurcissent l'accès, comme somewhere the passphrase doit être configuré de sorte que la clé peut être utilisée. Pourtant, le cryptage de la clé peut quelque peu réduire les dégâts si la clé est volée.

Sans authentification du client la configuration des beats devrait être (au moins) comme:

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

Avec l'authentification client la configuration des beats doit être (au moins) comme:

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