Aller au contenu principal
Dernière mise à jour le

Créer des identifiants de service

Cet article décrit comment créer un objet d'informations d'identification de service dans Unity Catalog qui vous permet de régir l'accès de Databricks aux services cloud externes comme AWS Glue ou AWS Secrets Manager. Un identifiant de service dans Unity Catalog encapsule un identifiant cloud à long terme qui accorde l'accès à de tels services.

Les identifiants de service ne sont pas destinés à régir l'accès au stockage cloud utilisé comme emplacement de stockage géré de Unity Catalog ou comme emplacement de stockage externe. Pour ces cas d'utilisation, utilisez un identifiant de stockage. Consultez Connectez-vous au stockage d'objets cloud à l'aide de Unity Catalog.

remarque

Les informations d’identification de Service sont l'alternative à Unity Catalog pour les profils d'instance, avec l'avantage que l'accès n'est pas lié à une ressource de compute spécifique mais aux utilisateurs, groupes ou Service Principal.

Pour créer un identifiant de service permettant d'accéder aux services AWS, vous créez un rôle IAM qui autorise l'accès au service et référencez ce rôle IAM dans la définition des identifiants de service.

Avant de commencer​

Avant de créer un identifiant de service, vous devez satisfaire aux exigences suivantes :

Dans Databricks :

  • Workspace Databricks activé pour Unity Catalog.
  • CREATE SERVICE CREDENTIAL privilège sur le métastore Unity Catalog attaché au Workspace. Les administrateurs de compte et les administrateurs de métastore disposent de ce privilège par default. Si votre workspace a été activé automatiquement pour Unity Catalog, les administrateurs du workspace bénéficient également de ce privilège.

Dans votre compte AWS :

  • Un service AWS dans la même région que les workspaces auxquels vous souhaitez accéder aux données.
  • La possibilité de créer des rôles IAM.

Créez un identifiant de service qui référence un rôle IAM AWS​

Cette section explique comment :

  • Créez un rôle IAM qui répond aux exigences de Databricks pour accéder à un service AWS.
  • Comment créer un objet sécurisable d'identifiant de service dans Unity Catalog qui peut être utilisé pour accéder au service AWS depuis Databricks.

Étape 1 : Créez un rôle IAM​

Dans AWS, créez un rôle IAM qui donne accès au service auquel vous souhaitez que vos utilisateurs aient accès. Ce rôle IAM doit être défini dans le même compte que le service.

astuce

Si vous avez déjà créé un rôle IAM qui fournit cet accès, vous pouvez ignorer cette étape et passer directement à l'étape 2 : fournir les détails du rôle IAM à Databricks.

  1. Créez un rôle IAM qui permettra l'accès au service.

    La création de rôle est un processus en deux étapes. Dans cette étape, vous créez le rôle, en ajoutant une politique de relation de confiance *temporaire* et un ID externe de substitution que vous modifiez ensuite après avoir créé les informations d'identification du service dans Databricks.

    Vous devez modifier la politique de confiance après avoir créé le rôle, car votre rôle doit s'auto-imputer (c'est-à-dire qu'il doit être configuré pour se faire confiance). Le rôle doit donc exister avant que vous n'ajoutiez la déclaration d'auto-imputation. Pour plus d'informations sur les rôles auto-assumés, consultez cet article de blog Amazon. Pour plus d'informations sur la politique d'application du rôle auto-assumé de Databricks, consultez la Politique d'application du rôle auto-assumé.

    Pour créer la politique, vous devez utiliser un ID externe de substitut.

    1. Créez le rôle IAM avec une Politique de confiance personnalisée .

    2. Dans le champ Custom Trust Policy , collez la politique JSON suivante.

      Cette politique établit une relation de confiance inter-comptes afin que Unity Catalog puisse assumer le rôle d'accès au service au nom des utilisateurs de Databricks. Ceci est spécifié par l'ARN dans la section Principal. C'est une valeur statique qui fait référence à un rôle créé par Databricks. Veuillez noter que la politique est légèrement différente si vous utilisez Databricks sur AWS GovCloud ou AWS GovCloud DOD.

      La politique définit l'ID externe sur 0000 comme espace réservé. Vous mettrez à jour cela avec l'ID externe de votre identifiant de service à une étape ultérieure.

JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": ["arn:aws:iam::414351767826:role/unity-catalog-prod-UCMasterRole-14S5ZJVKOTYTL"]
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "0000"
        }
      }
    }
  ]
}

  1. Ignorer la configuration de la politique d’autorisations. Vous reviendrez pour l’ajouter à une étape ultérieure.

  2. Enregistrez le rôle IAM.

  3. Créez une politique IAM dans le même compte que le service.

    Voici deux exemples de politiques que vous pouvez utiliser comme lignes directrices. Un exemple de stratégie est pour un identifiant de service qui se connecte à AWS Glue. L'autre fait référence à AWS Secrets Manager. Les actions et ressources réelles que vous ajoutez dépendent du service auquel vous vous connectez et du niveau d'accès dont vous avez besoin. Consultez la documentation AWS IAM de votre service.

    L'action sts:AssumeRole est la même quel que soit le service.

Remplacez les valeurs suivantes :

  • <AWS-ACCOUNT-ID>: L'Identifiant du compte de votre compte AWS (pas votre compte Databricks).
  • <AWS-IAM-ROLE-NAME>: Le nom du rôle IAM AWS que vous avez créé à l'étape précédente.
JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": ["secretsmanager:GetResourcePolicy", "secretsmanager:GetSecretValue"],
      "Resource": ["arn:aws:secretsmanager:us-west-2:111122223333:secret:aes128-1a2b3c"],
      "Effect": "Allow"
    },
    {
      "Action": ["sts:AssumeRole"],
      "Resource": ["arn:aws:iam::<AWS-ACCOUNT-ID>:role/<AWS-IAM-ROLE-NAME>"],
      "Effect": "Allow"
    }
  ]
}

  1. Attachez la politique IAM au rôle IAM.

    Dans le tab Autorisation du rôle, joignez la politique IAM que vous venez de créer.

Étape 2 : Fournissez à Databricks les détails du rôle IAM​

**Autorisations requises** : Le CREATE SERVICE CREDENTIAL privilège. Les rôles d'administrateur de métastore et d'administrateur de compte incluent tous deux ce privilège. Les administrateurs de Workspace dans les Workspaces pour lesquels Unity Catalog a été activé disposent également automatiquement de ce privilège.

  1. Dans Databricks, connectez-vous à un Workspace lié au métastore.

  2. Cliquez sur Icône de données. le Catalogue .

  3. Cliquez sur le bouton **Données externes >**, accédez à l'onglet **tab**, puis sélectionnez **Créer un identifiant**.

  4. Sélectionner l' identifiant de service .

  5. Saisissez un **Nom d'identifiant**, l'ARN du rôle IAM qui autorise Unity Catalog à accéder au service sur votre tenant cloud, et un commentaire facultatif.

  6. Cliquez sur Créer .

  7. Dans la boîte de dialogue **Identifiant de service créé**, copiez l'**ID externe**.

    Vous pouvez également consulter l'ID externe à tout moment sur la page des détails des identifiants de service. Consultez Afficher un identifiant de service.

  8. Cliquez sur **OK**.

Étape 3 : Mettre à jour la politique du rôle IAM​

Dans AWS, modifiez la politique de relation d'approbation pour ajouter l'ID externe de votre identifiant de service et le rendre auto-assumable.

  1. Retournez à votre rôle IAM enregistré et accédez à l'onglet **Trust Relationships**.

  2. Modifiez la politique de relation de confiance comme suit :

    Ajoutez l'ARN suivant à l'instruction « Allow ». Remplacez <YOUR-AWS-ACCOUNT-ID> et <THIS-ROLE-NAME> par vos ID de compte et valeurs de rôle IAM réels.

    "arn:aws:iam::<YOUR-AWS-ACCOUNT-ID>:role/<THIS-ROLE-NAME>"

    Dans l'instruction "sts:AssumeRole", mettez à jour l'ID externe d'espace réservé avec l'ID externe de l'identifiant de service que vous avez copié à l'étape précédente.

    "sts:ExternalId": "<SERVICE-CREDENTIAL-EXTERNAL-ID>"

    Votre politique devrait maintenant ressembler à ce qui suit, avec le texte de remplacement mis à jour pour utiliser les valeurs de l'ID externe de vos informations d'identification de service, de l'ID de compte et du rôle IAM :

    JSON
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "AWS": [
              "arn:aws:iam::414351767826:role/unity-catalog-prod-UCMasterRole-14S5ZJVKOTYTL",
              "arn:aws:iam::<YOUR-AWS-ACCOUNT-ID>:role/<THIS-ROLE-NAME>"
            ]
          },
          "Action": "sts:AssumeRole",
          "Condition": {
            "StringEquals": {
              "sts:ExternalId": "<SERVICE-CREDENTIAL-EXTERNAL-ID>"
            }
          }
        }
      ]
    }

Étape 4 : Valider l'identifiant de service​

Après avoir effectué les modifications de la politique de confiance du rôle IAM dans Étape 3 : Mettre à jour la politique de rôle IAM, vérifiez que votre rôle IAM est correctement configuré pour être utilisé comme identifiant de service :

  1. Dans Databricks, connectez-vous à un Workspace lié au métastore.
  2. Cliquez sur Icône de données. le Catalogue .
  3. Cliquez sur Icône de prise. Connecter , puis cliquez sur Identifiants .
  4. Sélectionnez l'identifiant de service que vous souhaitez valider.
  5. Cliquez Bouton Valider la configuration. La validation peut prendre de 1 à 2 minutes.
  6. Si l'une des vérifications échoue, revenez à l'Étape 3 : Mettre à jour la politique de rôle IAM et examinez la politique d'approbation du rôle IAM pour les configurer correctement.

Politique d'application des rôles auto-assumés​

Le 30 juin 2023, AWS a mis à jour sa politique d'approbation de rôle IAM pour exiger que les rôles IAM s'auto-approuvent explicitement pour les appels STS:AssumeRole. Par conséquent, Databricks exige que les rôles AWS IAM pour les identifiants de service soient auto-assumés et interdira bientôt les identifiants de service non auto-assumés. Pour plus de détails, consultez ce billet de blog de la communauté.

Databricks commencera à interdire la création d'identifiants de service avec des rôles IAM AWS non auto-assumés le 20 septembre 2024 . Les identifiants de service existants avec des rôles IAM non auto-assumés continueront de fonctionner, mais vous ne pourrez pas créer de nouveaux identifiants de service à l'aide de ces rôles.

Le **20 janvier 2025**, Databricks commencera à bloquer l'utilisation des informations d'identification de service existantes avec des rôles IAM non auto-assumés. **Cela peut potentiellement interrompre les charges de travail et les Jobs qui s'exécutent en utilisant des informations d'identification non auto-assumées.**

Pour vérifier si un rôle AWS IAM pour un identifiant de service est auto-assumé, suivez les instructions de l' Étape 4 : Valider l'identifiant de service. Si la vérification du Rôle d'auto-assumation échoue, veuillez revoir l' Étape 3 : Mettre à jour la politique de rôle IAM et reconfigurer la politique de confiance du rôle IAM pour se faire confiance.

(Facultatif) Attribuez une authentification de service à des workspaces spécifiques.​

Par default, un identifiant de service est accessible depuis tous les workspaces du métastore. Cela signifie que si un utilisateur s'est vu accorder un privilège sur cet identifiant de service, il peut exercer ce privilège à partir de n'importe quel workspace attaché au métastore. Si vous utilisez des Workspaces pour isoler l'accès aux données des utilisateurs, vous pouvez vouloir autoriser l'accès à un identifiant de service uniquement à partir de Workspaces spécifiques. Cette fonctionnalité est appelée liaison du workspace ou isolation des identifiants de service.

Un cas d'utilisation typique pour lier un identifiant de service à des workspaces spécifiques est le scénario dans lequel un administrateur cloud configure un identifiant de service à l'aide d'un identifiant de compte cloud de production, et que vous souhaitez vous assurer que les utilisateurs Databricks utilisent cet identifiant pour accéder à un service cloud externe uniquement dans le workspace de production.

Pour plus d'informations sur la liaison de workspace, consultez Attribuer des informations d'identification de stockage à des workspaces spécifiques et Liaison workspace-catalogue.

Associez un identifiant de service à un ou plusieurs workspaces​

Pour attribuer une information d'identification de service à des Workspaces spécifiques, utilisez l'Explorateur de catalogues.

Autorisations requises : administrateur du métastore ou propriétaire des identifiants de service.

remarque

Les administrateurs du metastore peuvent voir toutes les informations d'identification de service dans un metastore à l'aide de l'Explorateur de catalogues — et les propriétaires d'informations d'identification de service peuvent voir toutes les informations d'identification de service qu'ils possèdent dans un metastore — que ces informations d'identification de service soient ou non attribuées au Workspace actuel. Les informations d'identification du service qui ne sont pas attribuées au Workspace apparaissent grisées.

  1. Connectez-vous à un Workspace lié au métastore.

  2. Dans la barre latérale, cliquez sur Icône de données. Catalogue .

  3. Cliquez sur le bouton Données externes > et accédez à l'onglet tab .

  4. Sélectionnez l'identifiant de service et accédez à l'onglet **tab**.

  5. Dans l’onglet **tab**, décochez la case **Tous les Workspaces ont accès**.

    Si votre identifiant de service est déjà lié à un ou plusieurs Workspaces, cette case est déjà décochée.

  6. Cliquez sur Assigner aux workspaces et saisissez ou recherchez les workspaces que vous souhaitez assigner.

Pour révoquer l'accès, accédez à l'onglet Workspaces , sélectionnez le Workspace et cliquez sur Révoquer . Pour autoriser l'accès depuis tous les Workspaces, cochez la case Tous les Workspaces ont accès .

Étapes suivantes​

Limitations​

Les limitations suivantes s'appliquent :

  • Les versions 16.1 et antérieures de Databricks Runtime ne prennent en charge que Python.
  • Les SQL Warehouse prennent en charge les informations d’identification de service uniquement pour les UDF Python de Unity Catalog batch.
  • Certains événements d'audit pour les actions effectuées sur les identifiants de service n'apparaîtront pas dans la table system.access.audit. Les informations d'audit concernant la création, la suppression, la mise à jour, la lecture, la consultation ou l'utilisation d'un identifiant de service seront disponibles. Consultez référence de la table système des Audit Logs.
  • Pendant l'aperçu des informations d'identification de service, INFORMATION_SCHEMA.STORAGE_CREDENTIALS (obsolète) affichait à la fois les informations d'identification de stockage et les informations d'identification de service, et INFORMATION_SCHEMA.STORAGE_CREDENTIAL_PRIVILEGES (obsolète) affichait les privilèges qui s'appliquaient à la fois aux informations d'identification de stockage et aux informations d'identification de service. Ce n'est plus le cas. Vous devez plutôt utiliser INFORMATION_SCHEMA.CREDENTIALS et INFORMATION_SCHEMA.CREDENTIAL_PRIVILEGES pour les identifiants de stockage et de service.
Sur cette page