Architecture mutualisée sécurisée basée sur un compte de service Dataproc

L'architecture mutualisée sécurisée basée sur un compte de service Dataproc (appelée "architecture mutualisée sécurisée" ci-dessous) vous permet de partager un cluster avec plusieurs utilisateurs, avec un ensemble d'utilisateurs mappés à des comptes de service lors de la création du cluster. Avec l'architecture mutualisée sécurisée, les utilisateurs peuvent envoyer des charges de travail interactives au cluster avec des identités utilisateur isolées.

Lorsqu'un utilisateur envoie une tâche au cluster, la tâche :

  • s'exécute en tant qu'utilisateur d'OS spécifique avec un compte principal Kerberos spécifique

  • accède aux ressources Google Cloud à l'aide des identifiants du compte de service mappé.

Remarques et limites

Lorsque vous créez un cluster avec l'architecture mutualisée sécurisée activée, procédez comme suit :

  • Vous ne pouvez envoyer des tâches que via l'API Jobs de Dataproc.

  • Le cluster n'est disponible que pour les utilisateurs disposant de comptes de service mappés. Par exemple, les utilisateurs non mappés ne peuvent pas exécuter de tâches sur le cluster.

  • Les comptes de service ne peuvent être mappés qu'à des utilisateurs Google, et non à des groupes Google.

  • La passerelle des composants Dataproc n'est pas activée.

  • L'accès SSH direct au cluster et les fonctionnalités de Compute Engine, telles que l'exécution de scripts de démarrage sur les VM de cluster, sont bloqués. Par ailleurs, les tâches ne peuvent pas être exécutées avec des privilèges sudo.

  • Kerberos est activé et configuré sur le cluster pour permettre une communication sécurisée au sein des clusters. L'authentification de l'utilisateur final via Kerberos n'est pas prise en charge.

  • Les workflows Dataproc ne sont pas compatibles.

Créer un cluster d'architecture mutualisée sécurisée

Pour créer un cluster d'architecture mutualisée sécurisée Dataproc, utilisez l'option --secure-multi-tenancy-user-mapping pour spécifier la liste des mappages utilisateur vers compte de service.

Exemple :

La commande suivante crée un cluster avec l'utilisateur bob@my-company.com mappé au compte de service service-account-for-bob@iam.gserviceaccount.com et l'utilisateur alice@my-company.com mappé au compte de service service-account-for-alice@iam.gserviceaccount.com.

gcloud dataproc clusters create my-cluster \
    --secure-multi-tenancy-user-mapping="bob@my-company.com:service-account-for-bob@iam.gserviceaccount.com,alice@my-company.com:service-account-for-alice@iam.gserviceaccount.com" \
    --scopes=https://www.googleapis.com/auth/iam \
    --service-account=cluster-service-account@iam.gserviceaccount.com \
    --region=region \
    other args ...

Vous pouvez également stocker la liste des mappages utilisateur vers compte de service dans un fichier YAML ou JSON local ou Cloud Storage. Utilisez l'option --identity-config-file pour spécifier l'emplacement du fichier.

Exemple de fichier de configuration d'identité :

user_service_account_mapping:
  bob@my-company.com: service-account-for-bob@iam.gserviceaccount.com
  alice@my-company.com: service-account-for-alice@iam.gserviceaccount.com

Exemple de commande permettant de créer le cluster à l'aide de l'option --identity-config-file :

gcloud dataproc clusters create my-cluster \
    --identity-config-file=local or "gs://bucket" /path/to/identity-config-file \
    --scopes=https://www.googleapis.com/auth/iam \
    --service-account=cluster-service-account@iam.gserviceaccount.com \
    --region=region \
    other args ...

Remarques :

  • Comme indiqué dans les commandes ci-dessus, le cluster --scopes doit inclure au moins https://www.googleapis.com/auth/iam, ce qui est nécessaire pour que le compte de service du cluster puisse agir sous emprunt d'identité.

  • Le compte de service du cluster doit être autorisé à emprunter l'identité des comptes de service mappés aux utilisateurs (consultez la section Autorisations de compte de service).

  • Recommandation : Utilisez des comptes de service de cluster différents pour différents clusters afin de permettre à chaque compte de service de cluster d'emprunter l'identité d'un groupe limité et défini de comptes de service utilisateur mappés.