Administration Hadoop multitenant avancée – protection de Zookeeper

Contexte

Zookeeper est un composant critique au fonctionnement d’Hadoop en haute disponibilité. Ce dernier se protège en limitant le nombre de connexions max (maxConns=400). Cependant Zookeeper ne se protège pas intelligemment, il refuse les connexions une fois le seuil atteint. Dans ce cas les composants cœur (HBase RegionServers/HDFS ZKFC) ne pourront plus initialiser une connexion et le service sera alors dégradé voir indisponible !

Or il est très facile de faire une attaque de type DoS sur Zookeeper. D’autre part ces attaques sont souvent involontaires. Il suffit qu’un développeur manque de vigilance et lance un code custom qui ouvre des sessions zookeeper en boucle sans les fermer. Dans ce cas zookeeper est compromis, et l’ensemble des composants avec lui.

Solutions

Plusieurs contournements peuvent être mis en place, indépendamment ou conjointement.

Utilisation des Observers

Les observers sont des nœuds zookeepers particuliers :

  • Ils ne participent pas au Quorum
  • Ils se synchronisent sur les nœuds participants
  • Ils transfèrent les requêtes en écriture sur les nœuds participants

Ils permettent donc d’augmenter le nombre de nœuds sans ralentir le processus d’élection.

Utilisation de IPtables

Il est possible de se protéger des DoS externes via IPTables. En effet nous pouvons limiter le nombre de connexions sur le port de zookeeper (2181) par adresse IP. Cela permet de mettre une limite inférieur au maxConns de zookeeper et ainsi bloquer une adresse particulière sans bloquer l’accès depuis une autre machine.

Exemple

Imaginons la topologie de cluster suivante :

  • 3 edge nodes : edge1.adaltas.com, edge2.adaltas.com edge3.adaltas.com
  • 3 master nodes : master1.adaltas.com, master2.adaltas.com, master3.adaltas.com
  • n worker nodes : n’interviennent pas dans ce cas
  • Ces machines se situe dans le sous réseau : 10.10.10.0/24

On utilise les master nodes comme le quorum électif et les edges comme observers pour monter en charge

NB: le nombre pair de nœuds n’est pas un problème, seul 3 sont participants

Configuration Zookeeper

On met en place ces configurations (/etc/zookeeper/conf/zoo.cfg):

Sur les noeuds master:

Sur les noeuds edge:

Sur les nœuds master, on interdit la communication avec des machines externes sur le port 2181 (seul le réseau local est autorisé) via la règle IPTables suivante :

Ainsi ces instances zookeeper ne sont accédés que par nos services et processus internes.

Sur les nœuds edges, on limite la communication avec des machines externes sur le port 2181 à 100 connexions simultanées par IP via la règle :

Configuration Hadoop

Pour les services Hadoop (HDFS ZKFC, HBase Master, etc), on spécifie la chaine de connexion suivante :

master1.adaltas.com:2181,master2.adaltas.com:2181,master3.adaltas.com:2181

Pour les configurations “clientes” (Containers YARN, hbase client, applications tierces, etc.) on spécifie la chaîne :

Ainsi, lorsqu’un job ou une application externe se lance, ce dernier ne peut pas saturer le quorum et ne compromet pas l’état du cluster.

Aller plus loin

Silotage des nœuds observers

Si une application externe “frauduleuse” utilise la chaine

edge1.adaltas.com:2181,edge2.adaltas.com:2181,edge3.adaltas.com:2181

alors il est possible qu’elle sature les 3 nœuds observers. Ainsi, bien que le cluster reste stable, certains services seront indisponibles, puisque les clients ne pourront plus consulter zookeeper.

On peut limiter l’impact de la saturation des observers en décomposant la chaîne en plusieurs sous-chaînes que l’on spécifiera dans les configurations clientes. Exemple :

  • chaîne 1 : edge1.adaltas.com, edge2.adaltas.com
  • chaîne 2 : edge1.adaltas.com, edge3.adaltas.com
  • chaîne 3 : edge2.adaltas.com, edge3.adaltas.com

Ainsi si la chaîne 1 est saturée, edge3 reste disponible. Les applications ciblant la chaîne 2 et 3 ne seront donc pas bloquées.

Par |2018-06-05T22:37:04+00:00July 5th, 2017|Blog|0 commentaire

À propos de l'auteur :

Laisser un commentaire