Introduction

Cette procédure permet d'activer le chiffrement des communications :

• entre les membres du cluster,
• entre les clients (  Shinken ) et le cluster.

Pour éviter une interruption de service, les étapes doivent être suivies dans l'ordre.

Générer les certificats SSL

On utilise la version d'OpenSSL livrée par Shinken pour créer les certificats.

Sur un des nœuds du cluster, on se place dans un dossier qui va stocker tous nos certificats :

mkdir /etc/shinken/certs/mongodb
cd /etc/shinken/certs/mongodb

Création des certificats de l'autorité de certification

Remplacer Organization Inc. par le nom de la société du client ( éventuellement ).

/opt/shinken/openssl/bin/openssl genrsa 2048 > ca-key.pem 
/opt/shinken/openssl/bin/openssl req -new -x509 -nodes -days 365000 -key ca-key.pem -out ca-cert.pem -subj "/C=FR/L=Paris/O=Organization Inc./OU=Shinken MongoDB CA/CN=Shinken MongoDB CA"

Création des certificats pour les nœuds du cluster

Pour chaque nœud du cluster, exécuter la commande suivante :

• en remplaçant server1 par le nom de chaque nœud tel que définis dans la configuration du cluster.
• en remplaçant Organization Inc. par la valeur utilisée pour le certificat de l'autorité de certification ci-dessus.
  
  

/opt/shinken/openssl/bin/openssl req -newkey rsa:2048 -nodes -days 365000 -keyout server1-key.pem -out server1-req.pem -subj "/C=FR/L=Paris/O=Organization Inc./OU=Shinken MongoDB Cluster/CN=server1"
/opt/shinken/openssl/bin/openssl x509 -req -days 365000 -set_serial "0x`openssl rand -hex 8`" -in server1-req.pem -out server1-cert.pem -CA ca-cert.pem -CAkey ca-key.pem
cat server1-key.pem server1-cert.pem > server1.pem

Création des certificats pour les clients ( serveurs Shinken utilisant mongos )

• Pour chaque serveur Shinken qui va se connecter au cluster via mongos, exécuter la commande suivante :
  • En remplaçant client1 par le nom du serveur Shinken, tel qu'il est connu par le serveur DNS,
  • En remplaçant Organization Inc. par la valeur utilisée pour le certificat de l'autorité de certification ci-dessus.
    
    

/opt/shinken/openssl/bin/openssl req -newkey rsa:2048 -nodes -days 365000 -keyout client1-key.pem -out client1-req.pem -subj "/C=FR/L=Paris/O=Organization Inc./OU=Shinken MongoDB Client/CN=client1"
/opt/shinken/openssl/bin/openssl x509 -req -days 365000 -set_serial "0x`openssl rand -hex 8`" -in client1-req.pem -out client1-cert.pem -CA ca-cert.pem -CAkey ca-key.pem
cat client1-key.pem client1-cert.pem > client1.pem

Déployer les certificats sur les noeuds du cluster

Remplacer node2 et node3 par les noms ou IP des deux autres membres du cluster :

rsync -avP --delete /etc/shinken/certs/mongodb/ node2:/etc/shinken/certs/mongodb/
rsync -avP --delete /etc/shinken/certs/mongodb/ node3:/etc/shinken/certs/mongodb/

Déployer les certificats sur les clients ( serveurs Shinken utilisant mongos )

Remplacer client1 par le nom ou l'IP du serveur Shinken qui va se connecter au cluster :

rsync -avP /etc/shinken/certs/mongodb/ca-cert.pem /etc/shinken/certs/mongodb/client1.pem client1:/etc/shinken/certs/mongodb/

Activer le chiffrement sur le cluster

Autoriser le chiffrement des connexions au cluster

Pour éviter une coupure de service, intervenir sur chaque nœud du cluster, l'un après l'autre. L'arrêt d'un seul nœud sera transparent pour la production.

Cette première étape permet de configurer mongod pour accepter les connexions entrantes chiffrées, mais il se connectera toujours aux autres nœuds en clair.

• Sur chaque nœud du cluster, éditer /etc/mongod.conf pour ajouter cet extrait à la configuration, en remplaçant NODEX par le nom de chaque nœud :
  
  

net:
  ssl:
    mode: allowSSL
    PEMKeyFile: /etc/shinken/certs/mongodb/NODEX.pem
    CAFile: /etc/shinken/certs/mongodb/ca-cert.pem

• puis appliquer le changement :
  
  

service mongod restart

Activer le chiffrement des connexions entre les membres du cluster

Il faut maintenant configurer mongod pour lui dire d'établir ses connexions vers les autres membres du cluster avec le chiffrement. Les connexions entrantes sont toujours acceptées en clair et en chiffré.

• Sur chaque nœud du cluster, lancer un shell mongo vers les mongod :
  
  

mongo --port 27018

• puis exécuter la commande suivante :
  
  

db.adminCommand( { setParameter: 1, sslMode: "preferSSL" } )

• pour rendre la modification permanente, remplacer allowSSL  par preferSSL dans /etc/mongod.conf , inutile de redémarrer mongod, la configuration étant déjà appliquée :
  
  

net:
  ssl:
    mode: preferSSL 

Autoriser le chiffrement des connexions aux mongo-configsrv

Pour éviter une coupure de service, intervenir sur chaque nœud du cluster, l'un après l'autre. L'arrêt d'un seul nœud sera transparent pour la production.

Cette première étape permet de configurer mongod pour accepter les connexions chiffrées et en clair. Les mongos se connectant toujours en clair pour le moment, nil faut préparer le terrain pour pouvoir les passer en connexions chiffrées.

• Sur chaque nœud du cluster, éditer /etc/mongo-configsrv.conf pour ajouter cet extrait à la configuration, en remplaçant NODEX par le nom de chaque nœud :
  
  

net:
  ssl:
    mode: preferSSL
    PEMKeyFile: /etc/shinken/certs/mongodb/NODEX.pem
    CAFile: /etc/shinken/certs/mongodb/ca-cert.pem

• puis appliquer le changement :
  
  

service mongo-configsrv restart

Activer le chiffrement depuis les mongos ( clients Shinken )

Maintenant que tous les démons du cluster acceptent les connexions chiffrées, il faut configurer mongos pour établir des connexions chiffrées.

• Sur chaque nœud du cluster et sur chaque serveur Shinken se connectant au cluster, éditer le fichier /etc/mongos.conf pour ajouter cet extrait à la configuration, en remplaçant NODEX par le nom du serveur où est faite l'édition :
  
  

net:
  ssl:
    mode: preferSSL
    PEMKeyFile: /etc/shinken/certs/mongodb/NODEX.pem
    CAFile: /etc/shinken/certs/mongodb/ca-cert.pem

• puis appliquer le changement :
  
  

service mongos restart

Forcer le chiffrement des connexions aux mongo-configsrv

Une fois les mongos configurés pour utiliser le chiffrement, on peut bloquer les connexions entrantes en clair sur les mongo-configsrv.

Pour éviter une coupure de service, intervenir sur chaque noeud du cluster, l'un après l'autre. L'arrêt d'un seul noeud sera transparent pour la production.

• Sur chaque noeud du cluster, éditer /etc/mongo-configsrv.conf pour remplacer preferSSL  par requireSSL 

net:
  ssl:
    mode: requireSSL

• puis appliquer le changement

service mongo-configsrv restart

Forcer le chiffrement des connexions au cluster

Cette dernière étape permet de configurer mongod sur les nœuds du cluster pour n'accepter que des connexions chiffrées.

• Sur chaque nœud du cluster, lancer un shell mongo :
  
  

mongo --port 27018

• puis exécuter la commande suivante :
  
  

db.adminCommand( { setParameter: 1, sslMode: "requireSSL" } )

• pour rendre la modification permanente, remplacer preferSSL  par requireSSL dans /etc/mongod.conf , inutile de redémarrer mongod , la configuration étant déjà appliquée
  
  

net:
  ssl:
    mode: requireSSL

La connexions de Shinken au cluster

Connexion de Shinken au cluster sur la boucle local ( 127.0.0.1 )

Shinken se connectant à mongos via la boucle locale ( 127.0.0.1 ), et mongos chiffrant ses communications vers le cluster, il n'y a rien à faire.

Les connexions de Shinken à mongos peuvent rester en clair. Le chiffrement n'aurait aucune valeur ajoutée, en plus de nécessiter un supplément de ressources CPU.

net:
  bindIp: 127.0.0.1

Si pour une contrainte interne, vous avez besoin de chiffrer la connexion sur la boucle local ( NON RECOMMANDÉ )

Les étapes suivantes décrivent comment activer le chiffrement SSL pour les connexions entre Shinken et les instances locales de mongos.

Cette opération entraînera nécessairement une indisponibilité de Shinken le temps de redémarrer celui-ci ainsi que les processus mongos.

Création des certificats pour Shinken et déploiement des certificats sur les serveurs

Sur le serveur avec le certificat d'autorité, exécuter les commandes suivantes : 

• Remplacer le champ subjectAltName par la liste des serveurs hébergeant au moins un des démons Shinken suivants : Synchronizer, Broker ou Scheduler ( dans le cas de la retention MongoDB ).
• • Pour ajouter une IP : "IP:IP_DU_SERVEUR"
  • Pour ajouter un nom DNS : "DNS:NOM_DU_SERVEUR"

/opt/shinken/openssl/bin/openssl req -newkey rsa:2048 -nodes -keyout shinken-key.pem -out shinken-req.pem -subj "/C=FR/L=Paris" -addext 'subjectAltName = DNS:shinken-node1, IP:shinken-node2' 
/opt/shinken/openssl/bin/openssl x509 -req -days 365000 -set_serial "0x`openssl rand -hex 8`" -in shinken-req.pem -out shinken-cert.pem -CA ca-cert.pem -CAkey ca-key.pem

cat shinken-key.pem shinken-cert.pem > shinken.pem

Ensuite, il est nécessaire de déployer le certificat sur toutes les machines hébergeant au moins un des démons Shinken suivants : Synchronizer, Broker ou Scheduler ( dans le cas de la retention MongoDB ).

Dans la commande suivante, adapter la valeur de SHINKEN_SERVEUR :  

rsync -avP /etc/shinken/certs/mongodb/shinken.pem SHINKEN_SERVEUR:/etc/shinken/certs/mongodb/

Activer le chiffrement SSL dans Shinken

Pour activer le chiffrement SSL dans Shinken, il faut préciser les paramètres de connexion dans le paramètre de l'uri de Mongo. 

• Tous les composants de Shinken qui se connectent à MongoDB doivent voir leur configuration modifiée sur le serveur de l'Arbiter.

• Voici la liste des éléments qui se connectent à MongoDB et dont la configuration doit être mise à jour :
  • Le démon Synchronizer : ( voir la page Paramètres globaux ( synchronizer.cfg ) ) ;
  • Le module event-manager-reader : ( voir la page Module event-manager-reader )  ;
  • Le module event-manager-writer :  ( voir la page Module event-manager-writer   )  ;
  • Le module Graphite-Perfdata  : ( voir la page Module Graphite-Perfdata )  ;
  • Le module MongoDB : ( voir la page Module MongoDB )  ;
  • Le module  MongodbRetention : ( voir la page Module MongodbRetention ( Rétention en base de données centralisée par royaume ) )  ;
  • Le module SLA du Broker : ( voir la page Module SLA )   ;
  • Le module SLA de la WebUI : ( voir la page Module SLA ( WebUI ) )   ;
  • Le module livedata-module-sla-provider ( voir la page Module livedata-module-sla-provider )  ;
  • Le collecteur de type discovery-import ( voir la page Collecteur de type discovery-import ( Scan NMAP ) ) ;

• Dans le cas de l'utilisation de l'outil tiers Grafana, il faut aussi modifier sur la ou les machines avec un carbon-cache le fichier de configuration /opt/graphite/conf/mongodb.conf  ( voir la page Grafana - v8.3.2 ) ;

Exemple d'uri qui active le chiffrement SSL : 

mongodb_uri=mongodb://localhost:27017/?safe=false&tls=true&tlsCertificateKeyFile=/etc/shinken/certs/mongodb/shinken.pem&tlsCAFile=/etc/shinken/certs/mongodb/ca-cert.pem

Forcer le chiffrement des connexions aux mongos

• Sur chaque serveur disposant du mongos, éditer /etc/mongos.conf  pour remplacer preferSSL par requireSSL 

net:
  ssl:
    mode: requireSSL

Redémarrage des mongos et de Shinken pour prendre en compte les modifications

Il faut dans l'ordre :

• éteindre Shinken sur tous les serveurs :

  service shinken stop

• Redémarrer tous les mongos : 

  service mongos restart

• Redémarrer Shinken sur tous les serveurs : : 

  service shinken start

Utilisation du client mongo en ligne de commande

Si un mongos est présent sur la machine locale, il suffit de se connecter normalement en clair au mongos.

Depuis une machine clientX , pour établir une connexion chiffrée vers un mongod sur serveurY , voici la ligne de commande à utiliser

mongo --ssl --sslCAFile /etc/shinken/certs/mongodb/ca-cert.pem --sslPEMKeyFile /etc/shinken/certs/mongodb/clientX.pem --port 27018 --host serveurY

mongo --ssl --sslCAFile /etc/shinken/certs/mongodb/ca-cert.pem --sslPEMKeyFile /etc/shinken/certs/mongodb/serveurY.pem --port 27018 --host serveurY

Supervision du cluster MongoDB en SSL

Shinken recommande de superviser le cluster MongoDB créé lors de la mise en place de la haute disponibilité pour la base de données de Shinken :

• Il faut tous d'abord mettre en place la supervision du cluster MongoDB  (  voir la page Haute disponibilité de la base MongoDB (mise en place d'un cluster)   )   .
• Puis adapter la supervision du cluster à l'activation du chiffrement  ( voir la page  Supervision d'un cluster MongoDB )