Configuration de la sécurité Dataproc

Lorsque vous créez un cluster Dataproc, vous pouvez activer Hadoop Secure Mode via Kerberos pour assurer la mutualisation via l'authentification, l'isolation et le chiffrement des utilisateurs dans un cluster Dataproc.

Authentification des utilisateurs et autres services Google Cloud Platform. L'authentification par utilisateur via Kerberos ne s'applique qu'au sein du cluster. Les interactions avec d'autres services Google Cloud, tels que Cloud Storage, continuent d'être authentifiées en tant que compte de service pour le cluster.

Activer le mode sécurisé Hadoop via Kerberos

L'activation de Kerberos et du mode sécurisé Hadoop pour un cluster inclura la distribution MIT de Kerberos et la configuration d'Apache Hadoop YARN, HDFS, Hive, Spark et les composants associés afin de l'utiliser pour l'authentification.

L'activation de Kerberos crée un Centre de distribution de clés (KDC) sur le cluster, qui contient les comptes de services principaux et un compte principal racine. Le compte principal racine est le compte disposant des autorisations d'administrateur sur le KDC sur le cluster. Il peut également contenir des comptes utilisateur principaux standards ou être connecté via une approbation inter-domaines à un autre KDC contenant les comptes utilisateur principaux.

Créer un cluster Kerberos

Vous pouvez utiliser Google Cloud CLI, l'API Dataproc ou la console Google Cloud pour activer Kerberos sur les clusters qui utilisent la version d'image 1.3 ou ultérieure de Dataproc.

Commande gcloud

Pour configurer automatiquement un nouveau cluster Dataproc Kerberos (version d'image 1.3 et ultérieure), utilisez la commande gcloud dataproc clusters create.

gcloud dataproc clusters create cluster-name \
    --image-version=2.0 \
    --enable-kerberos

Propriété du cluster : au lieu d'utiliser l'option --enable-kerberos comme indiqué ci-dessus, vous pouvez configurer automatiquement Kerberos en transmettant l'option --properties "dataproc:kerberos.beta.automatic-config.enable=true" à la commande "clusters create". (Consultez la section Propriétés du service Dataproc pour plus d'informations.)

API REST

Les clusters Kerberos peuvent être créés via la requête ClusterConfig.SecurityConfig.KerberosConfig dans le cadre d'une requête clusters.create. Vous devez définir enableKerberos sur true.

Console

Vous pouvez configurer automatiquement Kerberos sur un nouveau cluster en procédant comme suit : en sélectionnant « Activer » dans la section "Kerberos et Mode sécurisé Hadoop" le panneau "Gérer la sécurité" de Dataproc Créer un cluster de la console Google Cloud.

Créer un cluster Kerberos avec votre propre mot de passe principal racine

Suivez les étapes ci-dessous pour configurer un cluster Kerberos qui utilise votre mot de passe principal racine.

Configurer le mot de passe principal racine Kerberos

Le compte principal racine Kerberos est le compte disposant des autorisations d'administrateur pour le KDC sur le cluster. Pour fournir le mot de passe du compte principal racine Kerberos de manière sécurisée, les utilisateurs peuvent le chiffrer à l'aide d'une clé de service de gestion des clés (KMS), puis la stocker dans une Bucket Google Cloud Storage auquel le compte de service du cluster peut accéder. Le compte de service du cluster doit disposer du Rôle IAM cloudkms.cryptoKeyDecrypter.

  1. Accordez le rôle Cloud KMS CryptoKey Encrypter/Decrypter au compte de service du cluster :

    gcloud projects add-iam-policy-binding project-id \
        --member serviceAccount:project-number-compute@developer.gserviceaccount.com \
        --role roles/cloudkms.cryptoKeyDecrypter
    

  2. Créer un trousseau de clés

    gcloud kms keyrings create my-keyring --location global
    

  3. Créez une clé dans le trousseau de clés :

    gcloud kms keys create my-key \
        --location global \
        --keyring my-keyring \
        --purpose encryption
    

  4. Chiffrez votre mot de passe principal Kerberos :

    echo "my-password" | \
      gcloud kms encrypt \
        --location=global \
        --keyring=my-keyring \
        --key=my-key \
        --plaintext-file=- \
        --ciphertext-file=kerberos-root-principal-password.encrypted
    

    1. Importez le mot de passe chiffré dans un bucket Cloud Storage de votre projet.
      1. Exemple :
        gcloud storage cp kerberos-root-principal-password.encrypted gs://my-bucket
        

Créer le cluster

Vous pouvez activer Kerberos sur les clusters avec votre propre mot de passe principal racine à l'aide de la commande gcloud ou de l'API Dataproc.

Commande gcloud

Pour créer un cluster kerberos Dataproc (version d'image 1.3 et ultérieure), utilisez la commande gcloud dataproc clusters create.

gcloud dataproc clusters create cluster-name \
    --region=region \
    --image-version=2.0 \
    --kerberos-root-principal-password-uri=gs://my-bucket/kerberos-root-principal-password.encrypted \
    --kerberos-kms-key=projects/project-id/locations/global/keyRings/my-keyring/cryptoKeys/my-key

Utilisez un fichier de configuration YAML (ou JSON). Au lieu de transmettre les options kerberos-* à la commande gcloud comme indiqué ci-dessus, vous pouvez placer les paramètres kerberos dans un fichier de configuration YAML (ou JSON), puis référencer le fichier de configuration pour créer le cluster kerberos.

  1. Créez un fichier de configuration. Consultez les sections Certificats SSL, Paramètres Kerberos supplémentaires et Approbation croisée pour connaître les paramètres de configuration supplémentaires pouvant être inclus dans le fichier :
    root_principal_password_uri: gs://my-bucket/kerberos-root-principal-password.encrypted
    kms_key_uri: projects/project-id/locations/global/keyRings/mykeyring/cryptoKeys/my-key
  2. Utilisez la commande gcloud suivante pour créer le cluster kerberos :
    gcloud dataproc clusters create cluster-name \
        --region=region \
        --kerberos-config-file=local path to config-file \
        --image-version=2.0
    

Points à noter concernant la sécurité Dataproc supprime la forme déchiffrée du mot de passe après avoir ajouté le compte principal racine au KDC. Pour des raisons de sécurité, après avoir créé le cluster, vous pouvez décider de supprimer le fichier de mot de passe et la clé utilisée pour déchiffrer le code secret, et de supprimer le compte de service du rôle kmsKeyDecrypter. N'effectuez pas cette opération si vous envisagez d'effectuer un scaling à la hausse du cluster, ce qui nécessite le fichier de mot de passe et la clé, ainsi que le rôle associé au compte de service.

API REST

Les clusters Kerberos peuvent être créés via la requête ClusterConfig.SecurityConfig.KerberosConfig dans le cadre d'une requête clusters.create. Définissez enableKerberos sur "true", et définissez les champs rootPrincipalPasswordUri et kmsKeyUri.

Console

Lorsque vous créez un cluster avec la version d'image 1.3 ou supérieure, sélectionnez "Activer" dans la section "Kerberos et mode sécurisé Hadoop" du panneau "Gérer la sécurité" de la page Créer un cluster Dataproc dans la console Google Cloud, puis définissez les options de sécurité (décrites dans les sections suivantes).

OS Login

La gestion des KDC sur le cluster peut être effectuée avec la commande kadmin à l'aide du compte utilisateur racine Kerberos ou de sudo kadmin.local. Activez la connexion au système d'exploitation pour contrôler qui peut exécuter les commandes du super-utilisateur.

Certificats SSL

Dans le cadre de l'activation du mode sécurisé Hadoop, Dataproc crée un certificat autosigné pour activer le chiffrement SSL du cluster. Vous pouvez également fournir un certificat pour le chiffrement SSL du cluster en ajoutant les paramètres suivants au fichier de configuration lorsque vous créez un cluster kerberos :

  • ssl:keystore_password_uri : emplacement dans Cloud Storage du fichier KMS chiffré contenant le mot de passe du fichier de clés.
  • ssl:key_password_uri : emplacement dans Cloud Storage du fichier KMS chiffré contenant le mot de passe de la clé dans le fichier de clés.
  • ssl:keystore_uri : emplacement dans Cloud Storage du fichier keystore contenant le certificat générique et la clé privée utilisée par les nœuds du cluster.
  • ssl:truststore_password_uri : emplacement dans Cloud Storage du fichier chiffré KMS contenant le mot de passe du fichier truststore.
  • ssl:truststore_uri : emplacement dans Cloud Storage du fichier truststore contenant des certificats de confiance.

Exemple de fichier de configuration :

root_principal_password_uri: gs://my-bucket/kerberos-root-principal-password.encrypted
kms_key_uri: projects/project-id/locations/global/keyRings/mykeyring/cryptoKeys/my-key
ssl:
  key_password_uri: gs://bucket/key_password.encrypted
  keystore_password_uri: gs://bucket/keystore_password.encrypted
  keystore_uri: gs://bucket/keystore.jks
  truststore_password_uri: gs://bucket/truststore_password.encrypted
  truststore_uri: gs://bucket/truststore.jks

Paramètres Kerberos supplémentaires

Pour spécifier un domaine Kerberos, créez un cluster kerberos avec la propriété suivante ajoutée dans le fichier de configuration Kerberos :

  • realm : nom du domaine Kerberos sur le cluster.

Si cette propriété n'est pas définie, le domaine sera celui du nom d'hôte (en majuscules).

Pour spécifier la clé principale de la base de données KDC, créez un cluster kerberos avec la propriété suivante ajoutée dans le fichier de configuration Kerberos :

  • kdc_db_key_uri : emplacement dans Cloud Storage du fichier chiffré KMS contenant la clé principale de la base de données KDC.

Si cette propriété n'est pas définie, Dataproc génère la clé principale.

Pour spécifier la durée de vie maximale du ticket d'octroi du ticket (en heures), créez un cluster kerberos avec la propriété suivante ajoutée au fichier de configuration Kerberos :

  • tgt_lifetime_hours : durée de validité maximale du ticket TGT (ticket granting ticket ou ticket d'octroi de ticket) en heures.

Si cette propriété n'est pas définie, Dataproc définit la durée de vie du ticket d'octroi du ticket sur 10 heures.

Approbation de domaine croisé

Le KDC du cluster ne contient initialement que le principal administrateur racine et les principaux de service. Vous pouvez ajouter manuellement les principaux d'utilisateur ou établir une approbation de domaine croisé avec un serveur KDC ou Active Directory externe contenant les principaux. Il est recommandé d'utiliser Cloud VPN ou Cloud Interconnect pour se connecter à un serveur KDC/Active Directory sur site.

Pour créer un cluster kerberos compatible avec la confiance inter-domaines, ajoutez les paramètres répertoriés ci-dessous au fichier de configuration Kerberos lorsque vous créez un cluster kerberos. Chiffrez le mot de passe partagé avec KMS et stockez-le dans un bucket Cloud Storage auquel le compte de service de cluster peut accéder.

  • cross_realm_trust:admin_server : nom d'hôte ou adresse du serveur d'administration distant.
  • cross_realm_trust:kdc : nom d'hôte ou adresse du KDC distant.
  • cross_realm_trust:realm : nom du domaine distant à approuver.
  • cross_realm_trust:shared_password_uri : emplacement dans Cloud Storage du mot de passe partagé chiffré KMS.

Exemple de fichier de configuration :

root_principal_password_uri: gs://my-bucket/kerberos-root-principal-password.encrypted
kms_key_uri: projects/project-id/locations/global/keyRings/mykeyring/cryptoKeys/my-key
cross_realm_trust:
  admin_server: admin.remote.realm
  kdc: kdc.remote.realm
  realm: REMOTE.REALM
  shared_password_uri: gs://bucket/shared_password.encrypted

Pour activer l'approbation de domaine croisé avec un KDC distant, procédez comme suit :

  1. Ajoutez les éléments suivants dans le fichier /etc/krb5.conf du KDC distant :

    [realms]
    DATAPROC.REALM = {
      kdc = MASTER-NAME-OR-ADDRESS
      admin_server = MASTER-NAME-OR-ADDRESS
    }

  2. Créez l'utilisateur d'approbation :

    kadmin -q "addprinc krbtgt/DATAPROC.REALM@REMOTE.REALM"
    

  3. Lorsque vous y êtes invité, entrez le mot de passe de l'utilisateur. Le mot de passe doit correspondre au contenu du fichier de mot de passe partagé chiffré.

Pour activer l'approbation de domaine croisé avec Active Directory, exécutez les commandes suivantes dans PowerShell en tant qu'administrateur :

  1. Créez une définition KDC dans Active Directory :

    ksetup /addkdc DATAPROC.REALM DATAPROC-CLUSTER-MASTER-NAME-OR-ADDRESS
    

  2. Créez une approbation dans Active Directory :

    netdom trust DATAPROC.REALM /Domain AD.REALM /add /realm /passwordt:TRUST-PASSWORD
    
    Le mot de passe doit correspondre au contenu du fichier de mot de passe partagé chiffré.

Principal dataproc

Lorsque vous envoyez une tâche via l'API de tâches Dataproc à un cluster kerberos Dataproc, elle s'exécute en tant que compte principal kerberos dataproc à partir du domaine kerberos du cluster.

L'architecture mutualisée est compatible au sein d'un cluster kerberos Dataproc si vous envoyez une tâche directement au cluster, par exemple via SSH. Toutefois, si la tâche lit ou écrit dans d'autres services Google Cloud, tels que Cloud Storage, elle sert de compte de service du cluster.

Propriétés de cluster par défaut et personnalisées

Le mode sécurisé Hadoop est configuré via des propriétés dans les fichiers de configuration. Dataproc définit les valeurs par défaut pour ces propriétés.

Vous pouvez remplacer les propriétés par défaut lorsque vous créez le cluster avec l'option gcloud dataproc clusters create --properties ou en appelant l'API clusters.create et en définissant les propriétés SoftwareConfig (voir exemples de propriétés de cluster).

Mode haute disponibilité

En mode haute disponibilité, un cluster kerberos possède trois KDC : un sur chaque maître. Le KDC exécuté sur le "premier" maître ($CLUSTER_NAME-m-0) devient le KDC maître et sert également de serveur d'administration. La base de données du KDC maître est synchronisée avec les deux KDC d'instance dupliquée toutes les cinq minutes par le biais d'une tâche Cron ; les trois KDC diffusent le trafic en lecture.

Kerberos n'est pas compatible de manière native avec la réplication en temps réel ou le basculement automatique si le KDC maître est en panne. Pour effectuer un basculement manuel, procédez comme suit :

  1. Sur toutes les machines KDC, dans /etc/krb5.conf, remplacez admin_server par le nouveau nom de domaine complet du maître. Supprimez l'ancien nœud maître de la liste KDC.
  2. Sur le nouveau KDC maître, configurez une tâche Cron pour propager la base de données.
  3. Sur le nouveau KDC maître, redémarrez le processus admin_server (krb5-admin-server).
  4. Sur toutes les machines KDC, redémarrez le processus KDC (krb5-kdc).

Configuration du réseau

Pour vous assurer que les nœuds de calcul peuvent communiquer avec le serveur d'administration KDC et Kerberos s'exécutant sur le ou les maîtres, vérifiez que les règles de pare-feu VPC autorisent le trafic TCP ou UDP entrant sur le port 88 et le trafic TCP entrant sur le port 749 sur le ou les maîtres. En mode haute disponibilité, assurez-vous que les règles de pare-feu VPC autorisent le trafic TCP entrant sur le port 754 sur les maîtres afin d'autoriser la propagation des modifications apportées au KDC maître. Kerberos nécessite que le DNS inverse soit correctement configuré. En outre, pour le choix de l'URL canonique principale des services basés sur l'hôte, assurez-vous que le DNS inverse est correctement configuré pour le réseau du cluster.

Pour plus d'informations

Consultez la documentation MIT sur Kerberos.