Configurer les destinations de demande d'accès

Cette page explique où les demandes d’accès peuvent être envoyées et comment les configurer. Pour obtenir une vue d’ensemble des demandes d’accès (RFA), notamment la manière dont les utilisateurs les effectuent et comment elles sont suivies et examinées, voir Demandes d’accès.

Pour configurer les demandes d'accès avec Slack, Microsoft Teams ou un autre webhook, un administrateur d'Workspace doit d'abord les configurer en tant que destinations de notification. Voir Gérer les destinations de notification.

Types de destination

Les destinations peuvent être l'une des suivantes :

• URL de redirection vers le système de demande d'accès externe de votre organisation. Une seule URL de redirection peut être configurée par objet. Lorsqu’une URL est définie, aucune autre destination ne peut être configurée, et les utilisateurs sont redirigés vers cette URL au lieu de voir le formulaire de demande intégré au produit.

• Adresses e-mail

  Les e-mails de demande d'accès sont envoyés depuis noreply@databricks.com.

• Canaux Slack

• Canaux Microsoft Teams

• Endpoints de webhook. Pour la charge utile de la requête, voir Intégrer une destination de webhook.

Les destinations des demandes d'accès peuvent être configurées sur les objets suivants dans Unity Catalog : metastores, catalogues, schémas, tables, vues, volumes, fonctions, modèles, identifiants de stockage, identifiants de service, emplacements externes et connexions.

Configurer les destinations des demandes d’accès pour un métastore

La demande d’accès est activée sur tous les métastores avec des demandes envoyées default à l’adresse e-mail du propriétaire de l’objet. Vous pouvez mettre à jour les destinations default pour inclure des e-mails ou des webhooks supplémentaires, y compris les canaux de distribution Slack et Microsoft Teams, ou acheminer toutes les demandes via une URL de redirection. En outre, vous pouvez désactiver l’envoi de demandes à l’adresse e-mail du propriétaire de l’objet et configurer d’autres destinations.

Pour mettre à jour les destinations default d’un métastore, vous devez être administrateur du métastore :

1. Dans votre workspace Databricks, cliquez sur Catalogue .

2. En haut du volet Catalogue , cliquez sur l'icône d'engrenage et sélectionnez Metastore .

3. Sous l'onglet Détails , cliquez sur l'icône de modification en regard de Demandes d'accès .

   

4. Le paramètre Envoyer automatiquement les demandes d’accès aux propriétaires d’objets est activé default. Décochez cette option pour désactiver l'envoi de demandes à l'adresse e-mail du propriétaire de l'objet.

5. En option, configurez l’un des types de destination suivants :

   • E-mail et webhooks : Configurez une ou plusieurs adresses e-mail et/ou des webhooks pour recevoir des demandes. Pour envoyer des demandes à des Canaux de distribution Slack ou Microsoft Teams, configurez-les en tant que webhooks.
   • URL de redirection : Configurez une URL de redirection vers le système de demande d’accès externe de votre organisation. En définissant une URL de redirection, aucun autre type de destination ne peut être ajouté.

6. Cliquez sur Enregistrer .

Configurer les destinations des demandes d’accès sur des objets spécifiques

Les propriétaires d’objets, les utilisateurs possédant le privilège MANAGE sur l’objet et les administrateurs de métastore peuvent définir des destinations explicites sur un objet.

remarque

Vous pouvez refuser MANAGE ACCESS CONTROL pour empêcher les propriétaires d’objets et les utilisateurs disposant de MANAGE de définir des destinations. Les administrateurs du métastore ne sont pas affectés. Voir Politiques de DENY ABAC (bêta).

Si un objet possède une destination explicite définie, il remplace les destinations héritées des objets parents. La destination explicite est également héritée par les objets enfants qui n’ont pas leur propre destination définie. Voir Comment les destinations sont résolues.

Vous pouvez configurer les destinations à l'aide de Catalog Explorer, de l'API REST ou de Terraform.

Catalog Explorer

1. Dans votre workspace Databricks, cliquez sur Catalogue .

2. Sélectionnez un objet sécurisable.

3. Cliquez sur le menu kebab et sélectionnez Gérer les destinations des demandes d'accès .

4. Sélectionnez une ou plusieurs destinations e-mail ou externes, ou configurez une URL de redirection. Si une URL est sélectionnée, aucun autre type de destination ne peut être ajouté.

   

5. Cliquez sur Mettre à jour .

REST API

Utilisez l’ API Access Request Destinations pour définir des destinations sur une mesure de sécurité. PATCH remplace les destinations sur la mesure de sécurité. Si aucun n'a été précédemment défini, il les crée.

Bash

curl -X PATCH \
  https://<workspace-url>/api/3.0/rfa/destinations \
  -H "Authorization: Bearer $DATABRICKS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "destinations": [
      { "destination_id": "data-access@example.com", "destination_type": "EMAIL" }
    ],
    "securable": {
      "type": "TABLE",
      "full_name": "main.sales.orders"
    }
  }'

Terraform

Utilisez la ressource databricks_rfa_access_request_destinations.

Hcl

resource "databricks_rfa_access_request_destinations" "orders" {
  destinations = [
    {
      destination_id   = "data-access@example.com"
      destination_type = "EMAIL"
    }
  ]
  securable = {
    type      = "TABLE"
    full_name = "main.sales.orders"
  }
}

Intégrer une destination webhook

Lorsqu'une demande est routée vers une destination webhook, Databricks envoie une charge utile comme celle-ci :

JSON

{
  "requesterName": "<first-name> <last-name>",
  "objectName": "<catalog>.<schema>.<table>",
  "objectType": "Table",
  "privileges": "SELECT",
  "principalName": "<user-name>",
  "onBehalfOf": "<user-name> (<email>)",
  "onBehalfOfType": "User Principal",
  "comment": "I need access to run queries on this table.",
  "databricksWorkspaceUrl": "https://<account>.databricks.com/explore/data/<catalog>/<schema>/<table>?o=<workspace-id>&activeTab=permissions&showGrantModal=true&requestedPrivileges=SELECT"
}

Pour les principaux utilisateurs, onBehalfOf inclut l'e-mail entre parenthèses après le nom lorsqu'un e-mail est disponible. Pour les demandes de groupe, onBehalfOf est le nom du groupe et onBehalfOfType est Group.

Pour plus d'informations sur la manière d'intégrer les webhooks avec des outils courants, voir ce qui suit :

• Envoyer des alertes à Jira
• Comment intégrer des webhooks dans ServiceNow

Comment les destinations sont résolues

Databricks résout la destination de la demande pour un objet donné dans l’ordre suivant :

1. Destination explicite au niveau de l'objet : si l'objet a une destination explicite définie, la requête y est envoyée.
2. E-mail du propriétaire de l'objet : si le propriétaire de l'objet est un utilisateur individuel, la demande est envoyée à son adresse e-mail.
3. Destination de l’objet parent : Si le propriétaire de l’objet est un groupe ou un Service Principal, Databricks remonte la hiérarchie des objets et utilise la première destination explicite ou l’e-mail du propriétaire individuel trouvé.
4. Destination au niveau du métastore : si aucune destination n’est trouvée dans la hiérarchie des objets, la demande revient à la destination au niveau du métastore. Si aucune destination au niveau du métastore n’est définie, les utilisateurs ne peuvent pas demander l’accès à l’objet. Voir Configurer les destinations de demande d'accès pour un métastore.

En raison de cet ordre, une destination configurée à un niveau supérieur de la hiérarchie des objets Unity Catalog est héritée par tous les objets enfants qui n’ont pas leur propre destination. Une destination explicite sur un objet remplace les destinations héritées des objets parents.