Apache Ozone est un magasin d'objets distribué construit au-dessus du service Hadoop Distributed Data Store. Il peut gérer des milliards de fichiers petits et volumineux difficiles à gérer par d'autres systèmes de fichiers distribués. Ozone prend en charge des API riches telles qu'Amazon S3, Kubernetes CSI ainsi que les API natives du système de fichiers Hadoop. Cela rend Ozone facilement consommable par différents types de charges de travail Big Data telles que l'entrepôt de données sur Apache Hive, l'ingestion de données avec Apache Nifi, le streaming avec Apache Spark/Flink et l'apprentissage automatique avec Tensorflow.
Avec l'empreinte croissante des données et les charges de travail multiformes qui nécessitent une collaboration entre différents groupes, la sécurité des données est de la plus haute importance. La sécurité Ozone a été ajoutée depuis la version Apache Hadoop Ozone 0.4.0 avec les contributions des communautés. Il a également été inclus en tant qu'aperçu technique dans la version CDP Data Center 7.0 de Cloudera. La sécurité peut être classée en quatre éléments de base :authentification, autorisation, audit et chiffrement. Nous couvrirons la partie Authentification de ce blog ainsi que les autres dans les suivantes.
L'authentification est le processus de reconnaissance de l'identité d'un utilisateur pour les composants Ozone. Ozone est compatible avec l'architecture de sécurité Apache Hadoop, prenant en charge une authentification forte à l'aide de Kerberos ainsi que des jetons de sécurité.
Authentification basée sur Kerberos
Comme le montre la figure 1 ci-dessous, les composants de service, y compris OM (Ozone Manager), SCM (Storage Container Manager) et Datandoes sont tous authentifiés les uns avec les autres via Kerberos. Chaque service doit être configuré avec un nom de principal Kerberos et un fichier keytab valides, qui seront utilisés par le service pour se connecter au démarrage du service en mode sécurisé. Plus de détails sur la configuration OM/SCM/Datanode Kerberos peuvent être trouvés dans les documents Apache Hadoop Ozone. De même, les clients Ozone doivent fournir soit un ticket Kerberos valide, soit des jetons de sécurité pour accéder aux services Ozone tels que Ozone Manager pour les métadonnées et Datanode pour les blocs de lecture/écriture.
Jetons de sécurité
Comme les jetons de délégation Hadoop, le jeton de sécurité Ozone a un identifiant de jeton ainsi qu'une signature signée de l'émetteur. Le gestionnaire Ozone émet des jetons de délégation et des jetons de bloc pour les utilisateurs ou les applications clientes authentifiées avec Kerberos. La signature du jeton peut être validée par des validateurs de jeton pour vérifier l'identité de l'émetteur. De cette façon, un détenteur de jeton valide peut utiliser le jeton pour effectuer des opérations sur les services du cluster comme s'il avait des tickets Kerberos de l'émetteur.
Jeton de délégation émis par Ozone Manager permet aux détenteurs de jetons d'accéder aux services de métadonnées fournis par Ozone Manager, tels que la création d'un volume ou la liste des objets dans un compartiment. Lors de la réception d'une demande d'un client avec un jeton de délégation, Ozone manager valide le jeton de délégation en vérifiant la signature du signataire via sa clé publique. Les opérations de jeton de délégation telles que l'obtention, le renouvellement et l'annulation ne peuvent être effectuées que sur une connexion authentifiée Kerberos.
Bloquer les jetons sont similaires aux jetons de délégation dans le sens où ils sont émis/signés par le responsable Ozone. Ils sont émis par Ozone manager lorsqu'une requête client implique la lecture ou l'écriture d'un bloc sur Datanode. Contrairement aux jetons de délégation demandés avec des API get/renew/cancel explicites, ils sont remis de manière transparente aux clients avec les informations d'emplacement de clé/bloc. Les jetons de bloc sont validés par Datanodes lors de la réception de la demande de lecture / écriture des clients utilisant la clé publique du chanteur chanteur Ozone. Le jeton de bloc ne peut pas être renouvelé explicitement par le client. Une fois expiré, le client doit récupérer à nouveau les emplacements de clé/bloc pour obtenir de nouveaux jetons de bloc.
Secret S3
Ozone prend en charge le protocole Amazon S3 via la passerelle Ozone S3. En mode sécurisé, Ozone Manager émet un secret s3 pour les utilisateurs authentifiés Kerberos ou les applications clientes accédant à Ozone à l'aide des API S3. Nous couvrirons cela dans des blogs ultérieurs sur la passerelle Ozone S3.
Comment fonctionne le jeton de sécurité Ozone ?
Comme le montre la figure 2, le jeton de délégation Apache Hadoop traditionnel et le jeton de bloc reposent sur des secrets partagés entre l'émetteur de jeton et le validateur de jeton pour signer et valider le jeton. Par conséquent, lorsque l'émetteur et le validateur sont différents, par exemple, dans le cas d'un jeton de bloc, la clé principale partagée doit être périodiquement transférée sur le câble pour se synchroniser entre l'émetteur du jeton (namenode) et le validateur du jeton (datanodes).
Au lieu de cela, le jeton de sécurité Ozone adopte une approche basée sur les certificats. Comme le montre la figure 3, il dissocie complètement les émetteurs de jetons et les validateurs de jetons avec une signature basée sur un certificat. De cette façon, les jetons sont plus sécurisés car les secrets partagés ne sont jamais transportés sur le réseau.
En mode sécurisé, SCM s'amorce en tant qu'autorité de certification (autorité de certification) et crée un certificat d'autorité de certification auto-signé. Datanode et Ozone Manager doivent s'enregistrer auprès de SCM CA via une CSR (demande de signature de certificat). SCM valide l'identité de Datanode et Ozone Manager via Kerberos et signe le certificat du composant. Les certificats signés sont utilisés par Ozone Manager et Datanode pour prouver son identité. Ceci est particulièrement utile pour la signature et la validation de jeton de délégation/jeton de bloc.
Dans le cas d'un jeton de bloc, Ozone Manager (émetteur de jeton) signe le jeton avec sa clé privée et Datanodes (validateur de jeton) utilise le certificat d'Ozone Manager pour valider les jetons de bloc car Ozone Manager et le datanode font confiance aux certificats signés par l'AC SCM.
Dans le cas d'un jeton de délégation lorsque Ozone Manager (à la fois émetteur et validateur de jeton) s'exécute en mode HA (haute disponibilité). Plusieurs instances d'Ozone Manager s'exécutent simultanément. Un jeton de délégation émis et signé par l'instance 1 d'Ozone Manager peut être validé par l'instance 2 d'Ozone Manager lorsque le responsable Ozone Manager change, car les deux instances font confiance aux certificats signés de l'AC SCM. Plus de détails sur le document de conception Ozone HA peuvent être trouvés ici.
Conclusion
L'authentification est l'un des éléments constitutifs les plus importants de la sécurité Apache Hadoop Ozone. Vous devriez maintenant avoir une meilleure compréhension des mécanismes d'authentification pris en charge par Apache Hadoop Ozone et de leur fonctionnement. Cela aidera à comprendre les autres piliers de la sécurité d'Ozone tels que l'autorisation et l'audit.
Restez à l'écoute pour des articles de suivi sur l'autorisation de sécurité de l'ozone, l'audit, le cryptage et le RGPD. Si vous êtes intéressé par la plongée en profondeur, vous pouvez trouver plus de détails techniques dans le document de conception de la sécurité de l'ozone.
Référence
[1] Architecture Apache Hadoop Ozone
[2] Analyse comparative d'Ozone :le stockage nouvelle génération de Cloudera pour CDP
[3] Qu'est-ce que Kerberos ? · Hadoop et Kerberos :la folie au-delà de la porte
[4] Document Apache Hadoop sur l'ozone
[5] Ajout de la sécurité à Apache Hadoop
[6] Document de conception Apache Hadoop Ozone HA sur HDDS-505.
[7] Document de conception de sécurité Apache Hadoop Ozone sur HDDS-4.
