Comment sécuriser votre cluster CoreOS avec les règles TLS / SSL et de pare-feu

Si vous envisagez d’exécuter un cluster CoreOS dans un environnement réseau indépendant de votre contrôle, tel qu’un centre de données partagé ou un accès Internet public, vous avez peut-être remarqué que + etcd + communique en effectuant des demandes HTTP non chiffrées. Il est possible d’atténuer les risques de ce comportement en configurant un pare-feu IPTables sur chaque nœud du cluster, mais une solution complète utiliserait idéalement une couche de transport chiffrée.

Heureusement, + etcd + prend en charge les connexions TLS / SSL entre homologues, de sorte que chaque membre d’un cluster est authentifié et que toutes les communications sont cryptées. Dans ce guide, nous allons commencer par provisionner un cluster simple avec trois membres, puis configurer les points de terminaison HTTPS et un pare-feu de base sur chaque ordinateur.

Ce guide s’appuie fortement sur les concepts abordés dans les this introduction aux composants du système CoreOS et https: //www.digitalocean. com / communauté / didacticiels / comment-configurer-un-cluster-sur-digitalocean [ce guide pour la mise en place d’un cluster CoreOS sur DigitalOcean].

Vous devez être familiarisé avec les bases des fichiers + etcd,` + fleetctl`, + cloud-config et à la génération d’une URL de découverte.

Pour créer et accéder aux machines de votre cluster, vous aurez besoin d’une clé publique SSH associée à votre compte DigitalOcean. Pour plus d’informations sur l’utilisation des clés SSH avec DigitalOcean, consultez la page voir ici.

Si vous souhaitez utiliser l’API DigitalOcean pour créer vos machines CoreOS, reportez-vous à la page https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-api-v2#how-to-generate- a-personal-access-token [ce didacticiel] pour plus d’informations sur la création et l’utilisation d’un jeton d’accès personnel avec des autorisations en écriture. L’utilisation de l’API est facultative, mais peut vous faire gagner du temps à long terme, en particulier si vous envisagez de créer de plus grands clusters.

Récupérez une nouvelle URL de découverte dans discovery.etcd.io, soit en visitant https://discovery.etcd.io/new?size=3 dans votre navigateur et en copiant l’URL affichée, soit en utilisant + curl + à partir du terminal votre machine locale:

Enregistrez l’URL renvoyée. nous allons l’utiliser dans notre + cloud-config + prochainement.

Nous allons commencer par écrire un + cloud-config. Le + cloud-config + sera fourni en tant que * données utilisateur * lors de l’initialisation de chaque serveur, définissant les détails de configuration importants pour le cluster. Ce fichier sera long, mais ne devrait pas être beaucoup plus compliqué que la version disponible dans la https://www.digitalocean.com/community/tutorials/how-to-set-up-a-coreos-cluster-on- digitalocean [guide de base des clusters]. Nous indiquerons explicitement à + flotte + de se servir des points de terminaison HTTPS, d’activer un service appelé + iptables-restore + pour notre pare-feu et d’écrire des fichiers de configuration indiquant «+ etcd » et « flotte +» où trouver les certificats SSL.

Ouvrez un terminal sur votre ordinateur local, assurez-vous de vous trouver dans votre répertoire personnel et utilisez + nano + (ou votre éditeur de texte favori) pour créer et ouvrir + ~ / cloud-config.yml +:

Collez le texte suivant, puis remplacez ++ dans la section + etcd2 + par l’URL de découverte que vous avez indiquée dans la dernière section.

Vous pouvez également supprimer la section + iptables-restore +, si vous ne souhaitez pas activer un pare-feu.

Soyez prudent avec l’indentation lors du collage. Le + cloud-config + est écrit en YAML, qui est sensible aux espaces blancs. Consultez les commentaires dans le fichier pour plus d’informations sur des lignes spécifiques. Nous passerons ensuite en revue certaines sections importantes plus en détail.

~ / cloud-config.yml

Vous pouvez également coller votre + cloud-config + dans the Validator officiel de CoreOS Cloud puis appuyez sur * Validate Cloud-Config *.

Enregistrez le fichier et quittez. Dans + nano +, vous pouvez accomplir cela avec * Ctrl-X * pour quitter, * y * pour confirmer l’écriture du fichier et * Entrée * pour confirmer le nom du fichier à enregistrer.

Voyons quelques blocs spécifiques de + cloud-init.yml +. Premièrement, les valeurs + flotte +:

Notez que + etcd_servers + est défini sur une URL + https +. Pour un fonctionnement HTTP simple, cette valeur n’a pas besoin d’être définie. Sans configuration explicite, cependant, HTTPS échouera. (+ $ private_ipv4 + est une variable comprise par le processus d’initialisation CoreOS, vous ne devez pas la modifier.)

Nous arrivons ensuite au bloc + write_files +. Les valeurs sont décomposées en un système de fichiers + chemin,` + autorisations` et + contenus, qui contient le contenu souhaité d’un fichier. Ici, nous spécifions que les fichiers unité + + systemd + des services + etcd2 + et + flotte + `doivent configurer des variables d’environnement pointant vers les certificats TLS / SSL que nous allons générer:

Bien que nous disions aux services où trouver les fichiers de certificat, nous ne pouvons pas encore fournir les fichiers eux-mêmes. Pour cela, nous devons connaître l’adresse IP privée de chaque ordinateur CoreOS, qui n’est disponible qu’une fois que les ordinateurs ont été créés.

Maintenant que nous avons défini un + cloud-config.yml +, nous allons l’utiliser pour provisionner chaque membre du cluster. DigitalOcean propose deux approches de base: via le panneau de commande Web ou en appelant l’API DigitalOcean à l’aide de cURL à partir de la ligne de commande.

Que vous utilisiez le Panneau de configuration ou l’API, vous devriez maintenant avoir trois Droplets en cours d’exécution. Il est maintenant temps de noter leurs adresses IP publiques et privées, disponibles en cliquant sur un droplet individuel dans le panneau de configuration, puis en cliquant sur le lien * Paramètres *. L’adresse IP privée de chaque Droplet sera nécessaire lors de la génération de certificats et de la configuration d’un pare-feu.

Testons une gouttelette. Assurez-vous que votre clé SSH est ajoutée à votre agent SSH local:

Recherchez l’adresse IP publique de * coreos-1 * dans le panneau de configuration de DigitalOcean et connectez-vous avec le transfert de l’agent SSH activé:

Lors de la première connexion à un membre du cluster, nous allons probablement recevoir un message d’erreur de + systemd +:

Cela indique que le pare-feu n’a pas encore été configuré. Pour le moment, il est prudent d’ignorer ce message. (Si vous avez choisi de ne pas activer le pare-feu dans votre + cloud-config +, vous ne verrez pas de message d’erreur. Vous pouvez toujours activer le service + iptables-restore + plus tard.)

Avant de nous préoccuper du pare-feu, voyons les instances + etcd2 + sur chaque membre du cluster en conversation.

CFSSL est une boîte à outils permettant de travailler avec des certificats TLS / SSL, publiée par CloudFlare. Au moment de la rédaction de cet article, c’est l’outil choisi par les développeurs CoreOS pour la génération de certificats auto-signés, de préférence pour OpenSSL et le désormais obsolète + etcd-ca +.

Avec les certificats en place, nous devrions pouvoir exécuter + fleetctl + sur * coreos-1 *. Commencez par vous connecter via SSH:

Ensuite, essayez de lister toutes les machines du cluster:

Vous devriez voir un identifiant pour chaque machine répertorié avec son adresse IP privée:

Si + flottectl + se bloque indéfiniment, il peut être nécessaire de redémarrer le cluster. Sortie sur votre machine locale:

Utilisez SSH pour envoyer des commandes + reboot + à chaque ordinateur CoreOS:

Attendez quelques instants, reconnectez-vous à * coreos-1 * et essayez à nouveau + fleetctl +.

Avec les certificats en place, il devrait être impossible pour les autres machines du réseau local de contrôler votre cluster ou d’extraire les valeurs de + etcd2 +. Néanmoins, c’est une bonne idée de réduire la surface d’attaque disponible si possible. Afin de limiter l’exposition de notre réseau, nous pouvons ajouter quelques règles de pare-feu simples à chaque machine, en bloquant la plupart du trafic réseau local provenant de sources autres que les pairs du cluster.

N’oubliez pas que si nous activons le service + iptables-restore + dans + cloud-config +, nous verrons un message d’erreur + systemd + lors de la première connexion à une machine CoreOS:

Cela nous permet de savoir que, même si le service est activé, le chargement de + iptables-restore + a échoué. Nous pouvons diagnostiquer cela en utilisant + systemctl +:

Il y a beaucoup d’informations ici, mais la ligne la plus utile est celle qui contient + iptables-restore [689] +, qui est le nom du processus que le système `+ systemd + 'a tenté d’exécuter avec son id de processus. C’est là que nous trouvons souvent le résultat d’erreur réel des services défaillants.

La restauration du pare-feu a échoué car, bien que nous ayons activé + iptables-restore + dans + cloud-config +, nous ne l’avons pas encore fourni avec un fichier contenant les règles souhaitées. Nous aurions pu le faire avant de créer les gouttelettes, sauf qu’il n’ya aucun moyen de savoir quelles adresses IP seront attribuées à un droplet avant sa création. Maintenant que nous connaissons chaque IP privée, nous pouvons écrire un ensemble de règles.

Ouvrez un nouveau fichier dans votre éditeur, collez ce qui suit et remplacez `, ` et ++ par l’adresse IP privée de chaque ordinateur CoreOS. Vous devrez peut-être également ajuster la section située sous + Accepter tout le trafic TCP / IP …​ + afin de refléter les services publics que vous avez l’intention d’offrir à partir du cluster, bien que cette version fonctionne bien à des fins de démonstration.

/ var / lib / iptables / rules-save

Copiez ce qui précède dans votre presse-papiers, connectez-vous à * coreos-1 * et ouvrez + rules-save + en utilisant https://www.digitalocean.com/community/tutorials/installing-and-us-us-vim-text -editor-on-a-cloud-server [Vim], l’éditeur de texte par défaut sous CoreOS:

Une fois dans l’éditeur, tapez +: set paste + et appuyez sur * Entrée * pour vous assurer que l’auto-indentation est désactivée, puis appuyez sur * i * pour passer en mode insertion et collez vos règles de pare-feu. Appuyez sur * Echap * pour quitter le mode insertion et sur *: wq * pour écrire le fichier et quitter.

Enfin, assurez-vous que le fichier dispose des autorisations appropriées (lecture et écriture pour l’utilisateur, lecture seule pour le groupe et l’univers):

Nous devrions maintenant être prêts à réessayer le service:

En cas de succès, + systemctl + se fermera silencieusement. Nous pouvons vérifier l’état du pare-feu de deux manières. Tout d’abord, en utilisant + systemctl status:

Et deuxièmement, en listant les règles + iptables + en vigueur:

Nous utilisons l’option + -v + pour obtenir une sortie commentée, ce qui nous permet de savoir à quelle interface une règle donnée s’applique.

Une fois que vous êtes certain que le pare-feu de * coreos-1 * est configuré, déconnectez-vous:

Ensuite, répétez cette procédure pour installer + / var / lib / iptables / rules-save + sur * coreos-2 * et * coreos-3 *.

Dans ce guide, nous avons défini un cluster CoreOS de base avec trois membres, fournissant à chacun un certificat TLS / SSL pour l’authentification et la sécurité du transport, et utilisé un pare-feu pour bloquer les connexions d’autres droplets sur le réseau du centre de données local. Cela permet de résoudre bon nombre des problèmes de sécurité de base liés à l’utilisation de CoreOS sur un réseau partagé.

À partir de là, vous pouvez appliquer les techniques décrites dans la suite de cette série sur la prise en main de CoreOS pour définir et gérer des services.