Hello
zaft a écrit :
Je bosse actuellement à construire une infra de calculateur pensée pour la disponibilité et la sécurité. En effet, ce type de machine tombe souvent en panne, et la présence de nombreux utilisateurs logués en ssh sur les frontales expose la configuration à un de grosses problématiques de sécurité. Il convient donc de réduire au maximum la surface d'attaque.
|
On est beaucoup à y avoir réflechi, comment concilier sécurité et HPC, et en fait, tu ne peux pas vraiment le faire.
Vu qu'une interruption de service de 1 min peut casser des calculs qui tournent depuis 1 semaine, tes utilisateurs vont au mieux te haïr et au pire rien comprendre si tu commences à appliquer toutes les updates de sécurité/firmware/etc, à rebooter des switchs, couper le ldap/dns, etc. C'est pas un cluster de serveur web, tu peux pas relancer les jobs en appuyant sur F5
En plus, une perturbation sur ton infra est susceptible de fausser les résultats des utilisateurs, et ça peut avoir des conséquences assez grave...
En plus tu verras, quand tu auras réussi à fiabiliser ton infra lustre, l'envie de faire des yum update tous les matins va vite te passer
Bref, sur ton cluster, quoique tu fasses, tu n'arriveras pas à maintenir un niveau de sécurité parfait.
La solution est de n'avoir qu'un seul point d'entrée au cluster, la frontale, de la sécuriser autant que tu peux et d'isoler ton cluster du monde extérieur en utilisant des vlans.
Ensuite, tu dois faire confiance à tes utilisateurs, quitte à leur faire signer une charte d'utilisation sur papier prévoyant le cas d'une utilisation malveillante (ban du compte, forward aux ressources humaines )
zaft a écrit :
Comment fonctionne un calculateur : les utilisateurs se loguent en ssh sur la frontale, y compilent leur code
|
Les utilisateurs ne devraient pas pouvoir compiler sur la frontale, ils devraient plutôt lancer un job pour compiler leur soft sur un noeud de calcul. Sinon tu vas te retrouver avec plusieurs utilisateurs qui font des tâches de compilation lourdes sur ta frontale, et la frontale sera lente pour tout le monde.
Et pour limiter la surface d'attaque, tu installes le minimum vital sur la frontale.
zaft a écrit :
Le serveur Ansible Master possède les clés ssh de l'ensemble de la configuration. Il n'écoute sur aucun ports coté machine (et l'ensemble des ports sont fermés), son seul accès se fait par un réseau dédié d'administration. Il n'est donc potentiellement pas vulnérable.
L'ensemble des services ssh n'écoutent que l'ip d'Ansible Master, à l’exception de la frontale qui écoute aussi sur une autre interface exposée au web (entrée utilisateurs).
|
Ce que tu veux faire, c'est un "bastion", un serveur d'administration qui a accès à tout au niveau réseau et peut se connecter à tous les serveurs en ssh (avec une clé ssh qui est dans tous les authorized_keys).
C'est indépendant du serveur de déploiement à mon avis.
zaft a écrit :
Ce serveur déploie le serveur de repository, qui contiendra l'ensemble des packages de la distribution, ainsi que les packages maisons. Cette machine possède un accès côté web, et expose un serveur http à l'ensemble de la configuration.
Puis sont déployé (PXE+DHCP, puis playbook ansible pour chacun) le reste des "pets", soit sur du dédié, soit dans des VMs : DNS, DHCP, NTP, PXE. Ces serveurs exposent leur services respectifs à l'ensemble des nodes de calcul (considérées jetables, comme en cloud, donc "catles" ), ainsi qu'à la frontale.
Le Job scheduleur est aussi déployé, sont rôle est de répartir les jobs des utilisateurs sur les nodes.
Je penses utiliser un outils comme oVirt pour passer l'ensemble de ces services en HA (en plus du modèle maitre-esclave pour chacun).
A noter que sur ce réseau "d'admin", je ne sais pas où mettre le DHCP et le PXE dédié. Pas sur Ansible master, trop risqué selon moi. Il faudra donc peut être considérer que deux serveurs sont de base nécessaires au déploiement et non un.
|
Perso j'ai fait ça avec des vlans:
* vlan access : le seul vlan sur lequel les connections externes sont autorisées, seule la frontale a une interface dans ce vlan
* vlan management : toutes les interfaces de management du matériel (BMC, CMC, baies de disques, etc) sont câblées dessus, le DHCP et le serveur de déploiement ont une pattes dedans (pour faire de l'IPMI).
* vlan production : tous les serveurs, la frontale, le stockage et les noeuds de calculs sont dessus, ce vlan est exposé aux utilisateurs.
Au niveau ACL réseau, tu filtres tout le trafic venant du vlan production vers le vlan management.
Ce que tu veux faire pour sécuriser encore plus, c'est un vlan supplémentaire, "admin", pour tous les services d'administration comme ssh, salt, pxe, etc.
D'expérience, c'est trop compliqué en pratique, j'ai fini par supprimer le vlan admin, ssh écoute sur toutes les interfaces réseaux et le déploiement se fait sur le vlan production.
Ensuite, j'ai un serveur de services (serveur debian+xen, avec un domU par service réseau), qui a une interface dans chaque vlan (prod et management). Ca permet de donner accès au vlan de management individuellement à chaque domU (ou pas).
zaft a écrit :
Puis vient la frontale et les nodes. Encore une fois, déployé par PXE+DHCP, et avec un playbook ansible pour terminer. Les nodes tombent souvent en panne car nombreuses. Elles seront redéployées au fur et à mesure selon la même méthode.
|
Pense à fixer ton dépot debian / yum local, pour ne pas avoir des versions différentes des paquets à chaque redéploiement. Le cluster doit rester aussi homogène que possible, et il faut éviter de passer des mises à jour sans les valider...
zaft a écrit :
Il manque ici le serveur de logs, ainsi que les serveurs de stockage type NFS/Lustre/Autre. J'aborderai le sujet par la suite.
http://s7.postimg.org/rqyiraz3d/Infra.png
Que pensez vous de cette configuration ? Est-elle viable dans la durée ? Et côté sécurité, y a t-il des choses anormales qui vous sautent au yeux ?
|
Un conseil, pour la sécurité, si tes systèmes sont bien configurés, ça ne sert à rien de faire des choses compliquées au niveau réseau.
Sinon tu vas finir par t'arracher les cheveux...
Bien sûr, si tu as des contraintes légales particulières (par exemple si tes utilisateurs manipulent des données médicales), ça vaut le coup de faire un effort supplémentaire.
zaft a écrit :
A noter que certains morceaux (réseau infiniband et lustre notamment) nécessitent parfois de recompiler le kernel sur les nodes dont la frontale, rendant du coup la mise à jours pourtant cruciale de cette dernière délicate...
|
Perso j'utilise le support infiniband fourni par debian ou redhat/centos (pas OFED), et j'ai jamais eu besoin de recompiler quoique ce soit.
Pour lustre, j'ai généré mes packages une fois pour le kernel stable debian, et je peux appliquer les updates de sécurité du noyau sans recompiler les modules lustre. Par contre, c'est impossible de faire passer des updates kernel et rebooter les serveurs sans un créneau de maintenance sur une infra HPC en prod.