Avec la configuration par défaut d'Apache HBase, tout le monde est autorisé à lire et à écrire dans toutes les tables disponibles dans le système. Pour de nombreuses configurations d'entreprise, ce type de politique est inacceptable.
Les administrateurs peuvent configurer des pare-feu qui décident quelles machines sont autorisées à communiquer avec HBase. Cependant, les machines qui peuvent passer le pare-feu sont toujours autorisées à lire et à écrire dans toutes les tables. Ce type de mécanisme est efficace mais insuffisant car HBase ne peut toujours pas différencier plusieurs utilisateurs qui utilisent les mêmes machines clientes, et il n'y a toujours pas de granularité en ce qui concerne l'accès à la table HBase, à la famille de colonnes ou au qualificateur de colonne.
Dans cet article, nous expliquerons comment Kerberos est utilisé avec Hadoop et HBase pour fournir l'authentification de l'utilisateur , et comment HBase implémente l'autorisation utilisateur pour accorder aux utilisateurs des autorisations pour des actions particulières sur un ensemble de données spécifié.
Secure HBase :authentification et autorisation
Une HBase sécurisée vise à protéger contre les renifleurs, les utilisateurs non authentifiés/non autorisés et les attaques basées sur le réseau. Il ne protège pas contre les utilisateurs autorisés qui suppriment accidentellement toutes les données.
HBase peut être configuré pour fournir l'authentification de l'utilisateur , qui garantit que seuls les utilisateurs autorisés peuvent communiquer avec HBase. Le système d'autorisation est mis en œuvre au niveau RPC et est basé sur la couche d'authentification simple et de sécurité (SASL), qui prend en charge (entre autres mécanismes d'authentification) Kerberos. SASL permet l'authentification, la négociation du chiffrement et/ou la vérification de l'intégrité des messages connexion par connexion (propriété de configuration "hbase.rpc.protection").
L'étape suivante après l'activation de l'authentification de l'utilisateur est de donner à un administrateur la possibilité de définir une série de règles d'autorisation d'utilisateur qui autorisent ou refusent des actions particulières. Le système d'autorisation, également connu sous le nom de coprocesseur de contrôleur d'accès ou liste de contrôle d'accès (ACL), est disponible à partir de HBase 0.92 (CDH4) et permet de définir une politique d'autorisation (lecture/écriture/création/administration), avec table/famille /granularité du qualificateur, pour un utilisateur spécifié.
Kerberos
Kerberos est un protocole d'authentification en réseau. Il est conçu pour fournir une authentification forte pour les applications client/serveur en utilisant la cryptographie à clé secrète. Le protocole Kerberos utilise une cryptographie forte (AES, 3DES, ...) afin qu'un client puisse prouver son identité à un serveur (et vice versa) via une connexion réseau non sécurisée. Une fois qu'un client et un serveur ont utilisé Kerberos pour prouver leur identité, ils peuvent également chiffrer toutes leurs communications pour garantir la confidentialité et l'intégrité des données dans le cadre de leurs activités.
Protocole d'échange de billets
De manière générale, pour accéder à un service utilisant Kerberos, chaque client doit suivre trois étapes :
- Authentification Kerberos :le client s'authentifie auprès du serveur d'authentification Kerberos et reçoit un Ticket Granting Ticket (TGT).
- Autorisation Kerberos :le client demande un ticket de service au serveur d'octroi de tickets, qui émet un ticket et une clé de session si le TGT client envoyé avec la demande est valide.
- Demande de service :le client utilise le ticket de service pour s'authentifier auprès du serveur qui fournit le service utilisé par le client (par exemple, HDFS, HBase, …)
HBase, HDFS, ZooKeeper SASL
Étant donné que HBase dépend de HDFS et de ZooKeeper, HBase sécurisé s'appuie sur un HDFS sécurisé et un ZooKeeper sécurisé. Cela signifie que les serveurs HBase doivent créer une session de service sécurisée, comme décrit ci-dessus, pour communiquer avec HDFS et ZooKeeper.
Tous les fichiers écrits par HBase sont stockés dans HDFS. Comme dans les systèmes de fichiers Unix, le contrôle d'accès fourni par HDFS est basé sur les utilisateurs, les groupes et les autorisations. Tous les fichiers créés par HBase ont "hbase" comme utilisateur, mais ce contrôle d'accès est basé sur le nom d'utilisateur fourni par le système, et toute personne pouvant accéder à la machine est potentiellement capable de "sudo" en tant qu'utilisateur "hbase". Secure HDFS ajoute les étapes d'authentification qui garantissent que l'utilisateur "hbase" est digne de confiance.
ZooKeeper a une liste de contrôle d'accès (ACL) sur chaque znode qui permet un accès en lecture/écriture aux utilisateurs en fonction des informations de l'utilisateur de la même manière que HDFS.
LCA HBase
Maintenant que nos utilisateurs sont authentifiés via Kerberos, nous sommes sûrs que le nom d'utilisateur que nous avons reçu est l'un de nos utilisateurs de confiance. Parfois, ce n'est pas assez de granularité - nous voulons contrôler qu'un utilisateur spécifié est capable de lire ou d'écrire une table. Pour ce faire, HBase fournit un mécanisme d'autorisation qui permet un accès restreint aux utilisateurs spécifiés.
Pour activer cette fonctionnalité, vous devez activer le coprocesseur Access Controller, en l'ajoutant à hbase-site.xml sous les classes de coprocesseur de serveur maître et de région. (Voir comment configurer la configuration de sécurité HBase ici.)
Un coprocesseur est un code qui s'exécute à l'intérieur de chaque serveur et/ou maître de région HBase. Il est capable d'intercepter la plupart des opérations (put, get, delete, …), et d'exécuter du code arbitraire avant et/ou après l'exécution de l'opération.
En utilisant cette capacité à exécuter du code avant chaque opération, le coprocesseur du contrôleur d'accès peut vérifier les droits de l'utilisateur et décider si l'utilisateur peut ou non exécuter l'opération.
Le shell HBase comporte quelques commandes qui permettent à un administrateur de gérer les droits d'utilisateur :
grant [table] [family] [qualifier]revoke [table] [family] [qualifier]
Comme vous le voyez, un administrateur a la possibilité de restreindre l'accès des utilisateurs en fonction du schéma de la table :
- Donnez à l'utilisateur-W des droits de lecture uniquement sur Table-X/Famille-Y (
grant 'User-W', 'R', 'Table-X', 'Family-Y') - Donnez à l'utilisateur-W les droits complets de lecture/écriture sur le qualificatif-Z (
grant 'User-W', 'RW', 'Table-X', 'Family-Y', 'Qualifier-Z')
Un administrateur a également la possibilité d'accorder des droits globaux, qui fonctionnent au niveau du cluster, tels que la création de tables, l'équilibrage des régions, l'arrêt du cluster, etc. :
- Donnez à User-W la possibilité de créer des tables (
grant 'User-W', 'C') - Donnez à l'utilisateur W la possibilité de gérer le cluster (
grant 'User-W', 'A')
Toutes les autorisations sont stockées dans une table créée par le coprocesseur Access Controller, appelée _acl_. La clé primaire de cette table est le nom de table que vous spécifiez dans la commande grant. La table _acl_ n'a qu'une seule famille de colonnes et chaque qualificatif décrit la granularité des droits pour une table/un utilisateur particulier. La valeur contient les droits réels accordés.
Comme vous pouvez le constater, les commandes du shell HBase sont étroitement liées à la manière dont les données sont stockées. La commande grant ajoute ou met à jour une ligne, et la commande revoke supprime une ligne de la table _acl_.
Access Controller sous le capot
Comme mentionné précédemment, le coprocesseur du contrôleur d'accès utilise la capacité d'intercepter chaque demande d'utilisateur et de vérifier si l'utilisateur a les droits d'exécuter les opérations.
Pour chaque opération, le contrôleur d'accès doit interroger la table _acl_ pour voir si l'utilisateur dispose des droits nécessaires pour exécuter l'opération.
Cependant, cette opération peut avoir un impact négatif sur les performances. La solution pour résoudre ce problème consiste à utiliser la table _acl_ pour la persistance et ZooKeeper pour accélérer la recherche des droits. Chaque serveur de région charge la table _acl_ en mémoire et est informé des modifications par ZkPermissionWatcher. De cette façon, chaque serveur de région a la valeur mise à jour à chaque fois et chaque vérification d'autorisation est effectuée à l'aide d'une carte en mémoire.
Feuille de route
Bien que Kerberos soit un système d'authentification stable, bien testé et éprouvé, la fonctionnalité HBase ACL est encore très basique et sa sémantique évolue encore. HBASE-6096 est le parapluie JIRA comme référence pour toutes les améliorations à livrer dans une version 2 de la fonctionnalité ACL.
Un autre sujet ouvert sur l'autorisation et le contrôle d'accès est la mise en œuvre d'un système de sécurité par KeyValue (HBASE-6222 ) qui donnera la possibilité d'avoir des valeurs différentes sur une même cellule associée à une étiquette de sécurité. Cela permettrait d'afficher une information particulière en fonction des autorisations de l'utilisateur.
Conclusion
HBase Security ajoute deux fonctionnalités supplémentaires qui vous permettent de protéger vos données contre les renifleurs ou d'autres attaques de réseau (en utilisant Kerberos pour authentifier les utilisateurs et chiffrer les communications entre les services), et vous permettent de définir des politiques d'autorisation utilisateur, de restreindre les opérations et de limiter la visibilité des données pour utilisateurs particuliers.
Matteo Bertozzi est ingénieur logiciel chez Spotify et consultant HBase chez Cloudera.
