Configurer l’autorisation dans une application Databricks

Databricks Apps prend en charge le développement d’applications sécurisé sur Azure Databricks. À mesure que les applications accèdent aux données et services d’un espace de travail, elles doivent utiliser des mécanismes d’authentification et d’autorisation qui appliquent des contrôles d’accès aux données et respectent les autorisations utilisateur. Le modèle d’autorisation Databricks Apps est basé sur OAuth 2.0 et combine les autorisations affectées à l’application avec celles de l’utilisateur qui y accède.

Pour prendre en charge cette infrastructure, Databricks Apps utilise deux modèles d’identité complémentaires :

• L’autorisation d’application donne à l’application sa propre identité avec un ensemble cohérent d’autorisations.
• L’autorisation utilisateur permet à l’application d’utiliser l’identité et les autorisations de l’utilisateur qui interagit avec lui.

Autorisation de l’application

Chaque application Azure Databricks a un principal de service dédié qui agit comme son identité lorsqu’elle accède aux ressources Azure Databricks. Ce principal de service est unique à l’instance d’application et ne peut pas être réutilisé entre les applications. Vous ne pouvez pas modifier le principal de service affecté à une application ou spécifier un principal de service existant lors de la création de l’application. Azure Databricks utilise cette identité pour évaluer les autorisations de l’application indépendamment de n’importe quel utilisateur, ce qui garantit que l’application ne peut accéder qu’aux ressources explicitement accordées, même en dehors du contexte d’interaction utilisateur.

Cette séparation permet d’appliquer des limites de sécurité, ce qui permet l’audit de l’activité d’application et prend en charge des scénarios tels que le traitement en arrière-plan ou les tâches automatisées.

Le principal de service est représenté par un ID unique. Copiez-la à partir de l’onglet Autorisation de l’application :

Lorsque vous créez une application, Azure Databricks provisionne automatiquement un principal de service dédié pour l’application. Le principal de service reste le même dans tous les déploiements de l’application. Lorsque vous supprimez l’application, Azure Databricks supprime le principal de service.

Utilisez le principal de service pour les actions que l’application effectue elle-même, sans nécessiter le contexte d’un utilisateur individuel. Les cas d’utilisation courants sont les suivants :

• Exécution de tâches en arrière-plan
• Lecture ou écriture de métadonnées ou de configuration partagée
• Journalisation des métriques d’activité ou d’utilisation
• Appel de services externes via des points de terminaison sécurisés

Toutes les actions initiées par l’application utilisent les autorisations du principal de service. Accordez au principal de service l’accès à des ressources spécifiques à l’aide d’attributions d’autorisations standard. Toutefois, elle ne prend pas en charge le contrôle d’accès au niveau de l’utilisateur. Tous les utilisateurs qui interagissent avec l’application partagent les mêmes autorisations définies pour le principal de service, ce qui empêche l’application d’appliquer des stratégies affinées en fonction de l’identité de l’utilisateur individuelle.

L’exemple suivant montre comment une application utilise son principal de service pour interroger des données dans le catalogue Unity :

Dans ce cas, le principal de service a besoin d’un accès explicite à l’entrepôt SQL et à la table catalogue Unity qu’il interroge.

Ce modèle fonctionne bien lorsque vous souhaitez que tous les utilisateurs de l’application voient les mêmes données ou lorsque l’application effectue des opérations partagées non liées aux contrôles d’accès spécifiques à l’utilisateur.

Récupérer les informations d’identification d’autorisation d’application

Pour l’autorisation d’application, Azure Databricks injecte automatiquement les informations d’identification du principal de service dans l’environnement de l’application. Les variables d’environnement suivantes contiennent les valeurs clientes OAuth requises :

Azure Databricks définit automatiquement les variables d’environnement dans le runtime de l’application. L’application utilise ces variables lorsqu’elle s’authentifie comme elle-même.

Python

import os

client_id = os.getenv('DATABRICKS_CLIENT_ID')
client_secret = os.getenv('DATABRICKS_CLIENT_SECRET')

JavaScript

const clientId = process.env.DATABRICKS_CLIENT_ID;
const clientSecret = process.env.DATABRICKS_CLIENT_SECRET;

Exemple : Interroger avec l’autorisation d’application

Python

Cet exemple utilise l’objet Config du Kit de développement logiciel (SDK), qui extrait les informations d’identification du principal de service à partir de variables d’environnement et effectue l’autorisation OAuth.

from databricks import sql
from databricks.sdk.core import Config

cfg = Config()

conn = sql.connect(
    server_hostname=cfg.host,
    http_path="<your-warehouse-http-path>",
    credentials_provider=lambda: cfg.authenticate,
)

query = "SELECT * FROM main.sandbox.sales_customers LIMIT 1000"

with conn.cursor() as cursor:
    cursor.execute(query)
    df = cursor.fetchall_arrow().to_pandas()
    print(df.head())

conn.close()

JavaScript

Cet exemple utilise des variables d’environnement pour s’authentifier auprès d’un principal de service à l’aide d’OAuth et exécuter une requête avec Databricks SQL Driver pour Node.js.

import { DBSQLClient } from '@databricks/sql';

const client = new DBSQLClient();

const connection = await client.connect({
  authType: 'databricks-oauth',
  host: process.env.DATABRICKS_SERVER_HOSTNAME,
  path: process.env.DATABRICKS_HTTP_PATH,
  oauthClientId: process.env.DATABRICKS_CLIENT_ID,
  oauthClientSecret: process.env.DATABRICKS_CLIENT_SECRET,
});

const query = 'SELECT * FROM main.sandbox.sales_customers LIMIT 1000';
const cursor = await connection.cursor(query);

const rows = [];
for await (const row of cursor) {
  rows.push(row);
}

console.log(rows.slice(0, 5)); // Like df.head()

await connection.close();

Autorisation de l’utilisateur

L’autorisation de l’utilisateur, parfois appelée autorisation au nom de l’utilisateur, permet à une application Databricks Apps d’agir avec l’identité de l’utilisateur de l’application. Azure Databricks transfère le jeton d’accès de l’utilisateur à l’application, qui utilise le jeton pour accéder aux ressources au nom de l’utilisateur. Azure Databricks applique toutes les autorisations en fonction des politiques existantes de l’utilisateur dans le catalogue Unity.

Pour gérer les risques de sécurité des applications agissant au nom d’un utilisateur, Azure Databricks utilise des étendues pour limiter les actions qu’une application peut effectuer via l’autorisation de l’utilisateur.

Appliquez l’autorisation utilisateur lorsque l’application doit respecter les autorisations individuelles de l’utilisateur. Les cas d’usage classiques sont les suivants :

• Interrogation de tables ou de volumes
• Accès aux entrepôts SQL ou au calcul
• Exécution de travaux ou de flux de travail liés à des actions utilisateur

Toutes les actions utilisent les autorisations de catalogue Unity existantes de l’utilisateur :

L’autorisation utilisateur permet un contrôle d’accès affiné en appliquant des fonctionnalités de catalogue Unity telles que des filtres au niveau des lignes et des masques de colonne à l’activité de l’application. Cette approche maintient le contrôle d’accès cohérent avec la gouvernance de l’espace de travail et évite la logique d’autorisation de codage en dur dans l’application.

Autorisations affinées avec autorisation de l’utilisateur

Lorsque vous ajoutez une autorisation utilisateur à une application, elle applique les autorisations existantes du catalogue Unity de l’utilisateur, notamment :

• Filtres au niveau des lignes pour restreindre les lignes visibles
• Masques de colonne pour censurer ou transformer des données sensibles

Étant donné qu’Azure Databricks évalue les demandes d’autorisation utilisateur avec l’identité de l’utilisateur, ces stratégies s’appliquent automatiquement lorsque l’application accède aux données. Par exemple, si une table inclut un filtre de lignes qui limite la visibilité par région, l’application retourne uniquement les lignes que l’utilisateur est autorisé à interroger. Aucune logique de filtrage supplémentaire n’est nécessaire dans l’application.

Cette approche évite de dupliquer la logique de contrôle d’accès dans le code d’application et garantit la cohérence avec la gouvernance au niveau de l’espace de travail. Lorsque les administrateurs mettent à jour les stratégies de catalogue Unity, l’application respecte automatiquement ces modifications.

Sécurité basée sur la portée et escalade des privilèges

Les applications qui utilisent l’autorisation utilisateur doivent déclarer des étendues d’autorisation spécifiques pour limiter ce que l’application peut faire au nom de l’utilisateur. Les étendues limitent l’accès à des API ou à des types de ressources spécifiques, tels que :

• sql pour interroger des entrepôts SQL
• dashboards.genie pour gérer votre espace Génie
• files.files pour la gestion de vos fichiers et répertoires

Si vous ne sélectionnez aucune étendue, Azure Databricks affecte un ensemble par défaut qui permet à l’application de récupérer les informations d’identité utilisateur de base :

• iam.access-control:read
• iam.current-user:read

Ces valeurs par défaut sont requises pour prendre en charge les fonctionnalités d’autorisation utilisateur, mais elles n’autorisent pas l’accès aux données ou aux ressources de calcul. Ajoutez des étendues supplémentaires lorsque vous créez ou modifiez l’application.

Les étendues appliquent le principe du privilège minimum. Veillez à configurer l’application pour demander uniquement les étendues dont elle a besoin. Azure Databricks bloque l’accès à n’importe quelle fonctionnalité en dehors des étendues approuvées, même si l’utilisateur dispose d’une autorisation. Par exemple, si une application demande uniquement sql l’étendue, elle ne peut pas accéder aux points de terminaison pour la mise en service des modèles, même si l’utilisateur peut le faire en dehors de l’application.

Lorsqu’un utilisateur accède d’abord à une application, Azure Databricks les invite à autoriser explicitement l’application à agir dans les étendues demandées. Les administrateurs peuvent éventuellement accorder le consentement au nom des utilisateurs pour aligner l’accès avec les stratégies organisationnelles.

Ajouter des étendues à une application

Configurez l’autorisation utilisateur lorsque vous créez ou modifiez une application dans l’interface utilisateur Azure Databricks.

Dans l’étape Configurer , cliquez sur +Ajouter une étendue et sélectionnez les étendues qui définissent les API ou ressources Azure Databricks auxquelles l’application peut accéder pour le compte de l’utilisateur. Azure Databricks applique ces étendues au moment de l’exécution et requiert le consentement de l’utilisateur ou de l’administrateur avant d’accorder l’accès.

Pour obtenir un exemple complet, consultez la démonstration d’autorisation Databricks Apps sur GitHub. L’exemple d’application montre comment utiliser des modèles d’autorisation utilisateur et d’application, et inclut des instructions de configuration et des exemples de requêtes avec autorisation utilisateur.

Récupérer les informations d’identification d’autorisation utilisateur

Pour l’autorisation utilisateur, Azure Databricks transfère l’identité et le jeton d’accès de l’utilisateur à l’application dans les en-têtes HTTP. L’application doit extraire ces en-têtes pour agir au nom de l’utilisateur.

La façon dont vous récupérez ces en-têtes dépend de l’infrastructure que vous utilisez.

Streamlit

import streamlit as st
user_access_token = st.context.headers.get('x-forwarded-access-token')

Gradio

import gradio as gr

def query_fn(message, history, request: gr.Request):
    access_token = request.headers.get("x-forwarded-access-token")
    ...

Gradio injecte automatiquement l’objet de requête dans la fonction de votre application si vous la déclarez en tant que paramètre. Vous n’avez pas besoin de construire ou d’extraire la requête manuellement.

Dash et Flask

from flask import request

headers = request.headers
user_token = headers.get('x-forwarded-access-token')

Shiny

user_token = session.http_conn.headers.get('x-forwarded-access-token')

Express

import express from 'express';

const userAccessToken = req.header('x-forwarded-access-token');

Exemple : Interroger avec l’autorisation de l’utilisateur

Dans ce cas, l’application transmet directement le jeton d’accès de l’utilisateur au connecteur, et Azure Databricks applique les autorisations de l’utilisateur à la requête.

Python

from databricks import sql
from databricks.sdk.core import Config
from flask import request

cfg = Config()
user_token = request.headers.get("x-forwarded-access-token")

conn = sql.connect(
    server_hostname=cfg.host,
    http_path="<your-warehouse-http-path>",
    access_token=user_token
)

query = "SELECT * FROM main.sandbox.sales_customers LIMIT 1000"

with conn.cursor() as cursor:
    cursor.execute(query)
    df = cursor.fetchall_arrow().to_pandas()
    print(df.head())

conn.close()

JavaScript

import { DBSQLClient } from '@databricks/sql';
import express from 'express';

const app = express();

app.get('/', async (req, res) => {
  const userToken = req.header('x-forwarded-access-token');

  const client = new DBSQLClient();
  const connection = await client.connect({
    authType: 'access-token',
    host: process.env.DATABRICKS_SERVER_HOSTNAME,
    path: process.env.DATABRICKS_HTTP_PATH,
    token: userToken,
  });

  const query = 'SELECT * FROM main.sandbox.sales_customers LIMIT 1000';
  const cursor = await connection.cursor(query);

  const rows = [];
  for await (const row of cursor) {
    rows.push(row);
  }

  console.log(rows.slice(0, 5));
  await connection.close();

  res.send('Query complete');
});

app.listen(3000);

Meilleures pratiques pour l’autorisation de l’utilisateur

Lorsque vous créez des applications qui effectuent des actions pour le compte des utilisateurs, suivez ces bonnes pratiques pour garantir un accès sécurisé et auditable :

• Rangez le code de l'application dans des dossiers accessibles uniquement au propriétaire de l'application ou à un petit groupe d'utilisateurs de confiance.
• Accordez des CAN MANAGE autorisations uniquement aux développeurs principaux approuvés responsables de la maintenance et de la révision des applications. Accordez CAN USE des autorisations uniquement aux utilisateurs ou groupes spécifiques approuvés pour exécuter l’application.
• Vérifiez que les jetons ne sont pas imprimés, enregistrés ou écrits dans des fichiers. Cela s’applique à toutes les instructions de journalisation, outils de débogage et gestionnaires d’erreurs. Par exemple, au lieu d’utiliser print(f"User token: {token}")headers = {"Authorization": f"Bearer {token}"}.
• Configurez chaque application pour demander uniquement les étendues d’autorisation minimales requises pour ses fonctionnalités.
• Pendant la révision du code, vérifiez que les paramètres d’étendue et d’autorisation s’alignent sur les exigences de sécurité et n’accordent pas d’accès inutile.
• Imposer la révision par les pairs pour tous les codes de l'application avant de déployer dans les environnements de production.
• Assurez-vous que le code de votre application enregistre les journaux d’audit structurés pour chaque action effectuée au nom des utilisateurs, notamment l’identité de l’utilisateur, le type d’action, la ressource cible et l’état.

Méthodes d’authentification

Pour obtenir des jetons pour Databricks Apps, les utilisateurs et les principaux de service s’authentifient à l’aide de flux OAuth 2.0 standard. La méthode varie selon que l’appelant est un utilisateur ou une charge de travail automatisée.

Pour la connexion de l’espace de travail (utilisateurs uniquement) :

• Authentification unique (SSO) : Les utilisateurs s’authentifient via votre fournisseur d’identité lorsque l’authentification unique est configurée.
• Mot de passe unique (OTP) : Les utilisateurs reçoivent un mot de passe temporaire si l’authentification unique n’est pas configurée.

Pour les flux OAuth (applications et charges de travail) :

• OAuth (Utilisateur à machine) : Les utilisateurs s’authentifient et les jetons résultants activent l’autorisation utilisateur afin que l’application puisse agir pour le compte de l’utilisateur.
• OAuth de machine à machine (M2M) : Les entités de service s'authentifient à l'aide des informations d'identification client ou de la fédération. Ces jetons sous-tendent l’autorisation d’application, où l’application agit en son propre nom plutôt qu'au nom d'un utilisateur.

Pour obtenir des instructions sur l’appel d’une application Databricks à l’aide de l’authentification par jeton, consultez Se connecter à une application Databricks API à l’aide de l’authentification par jeton.

Comparer et combiner des modèles

Databricks Apps peut utiliser l’application et l’autorisation utilisateur indépendamment ou ensemble. Ces modèles servent différents objectifs et sont conçus pour fonctionner en parallèle.