POC Databricks serverless, APIM et Azure OpenAI avec managed identity

17 May 2026

J'ai mené une POC pour valider un flux d'appel Azure OpenAI depuis Databricks via Azure API Management, sans secret applicatif, en s'appuyant sur des managed identities.

Objectif

Le scénario à valider était le suivant : un Job Databricks serverless exécute un notebook, obtient un token Entra ID via une Unity Catalog service credential, appelle APIM avec ce bearer token, puis APIM relaie vers Azure OpenAI avec sa propre managed identity.

Architecture testée

  • Azure Databricks workspace avec compute serverless pour le Job de test.
  • Databricks Access Connector portant une managed identity système.
  • Unity Catalog service credential de type SERVICE, associée à l'Access Connector.
  • Azure API Management en mode Consumption, avec managed identity système.
  • Azure OpenAI avec authentification locale désactivée côté Terraform.
  • Policy APIM validate-jwt pour contrôler le token entrant.

Schéma du flux

sequenceDiagram
    autonumber
    participant Job as Databricks Job serverless
    participant Cred as UC service credential
    participant MIDBX as MI Databricks Access Connector
    participant Entra as Microsoft Entra ID
    participant APIM as Azure API Management
    participant MIAPIM as MI APIM
    participant AOAI as Azure OpenAI

    Job->>Cred: getServiceCredentialsProvider()
    Cred->>MIDBX: Utilise l'Access Connector
    MIDBX->>Entra: Token pour cognitiveservices/.default
    Entra-->>Job: JWT aud=cognitiveservices + oid MI Databricks
    Job->>APIM: POST /openai/chat/completions + Bearer JWT
    APIM->>APIM: validate-jwt aud + issuer + oid
    APIM->>MIAPIM: authentication-managed-identity
    MIAPIM->>Entra: Token Azure OpenAI
    APIM->>AOAI: Chat completions
    AOAI-->>APIM: Réponse modèle
    APIM-->>Job: HTTP 200

Flux validé

  1. Le notebook Databricks appelle dbutils.credentials.getServiceCredentialsProvider(...).
  2. Databricks demande un token pour l'audience https://cognitiveservices.azure.com/.default.
  3. APIM reçoit l'appel sur un endpoint de proxy OpenAI.
  4. APIM valide l'audience, l'issuer et le claim oid de la managed identity Databricks.
  5. APIM obtient ensuite un token Azure OpenAI via authentication-managed-identity.
  6. Azure OpenAI répond à l'appel de chat completions.

Commandes de démarrage

terraform init
terraform validate
terraform plan -out=tfplan
terraform apply tfplan

./scripts/deploy-openai-model.sh
./scripts/deploy-databricks-mi-pipeline.sh

Point important découvert

La variante initiale utilisait une audience applicative api://... avec un app role. Ce modèle est classique pour protéger une API custom, mais le provider de service credential Databricks n'a pas accepté cette audience pour l'émission du token. Le test final utilise donc l'audience Azure https://cognitiveservices.azure.com, puis APIM restreint l'accès via le claim oid de la managed identity attendue.

Serverless et Conditional Access

Le test a bien été exécuté depuis un Job Databricks serverless. En revanche, le workspace Databricks n'est pas lui-même un VNet client : le compute serverless sort par le compute plane managé Databricks/Microsoft. Cela compte pour les environnements où des Conditional Access policies évaluent la localisation réseau du token endpoint Entra ID. La POC valide l'authentification par managed identity depuis Databricks serverless, mais ne prouve pas une sortie réseau depuis une IP publique maîtrisée par le tenant client.

flowchart LR
    subgraph ClientTenant["Tenant client"]
      DBX[Databricks workspace]
      AC[Access Connector MI]
      APIM[APIM]
      AOAI[Azure OpenAI]
    end

    subgraph ManagedPlane["Compute plane Databricks/Microsoft"]
      Serverless[Job serverless]
    end

    Serverless -->|Token request| Entra[Microsoft Entra ID]
    Serverless -->|HTTPS + Bearer token| APIM
    APIM -->|Managed identity| AOAI
    AC -. identity used by .-> Serverless

Pour reproduire un contexte avec IP source contrôlée, il faudrait compléter avec du serverless egress control Databricks si disponible, ou basculer vers du compute classique avec VNet injection et NAT Gateway.

Résultat

Le pipeline Databricks a retourné un HTTP 200 et une réponse modèle attendue mi-ok. Le token utilisé avait bien l'audience Azure attendue et l'identité correspondait à la managed identity de l'Access Connector.

Livrables

  • Terraform pour l'infrastructure Azure.
  • Script de déploiement du modèle Azure OpenAI.
  • Script de création et lancement du pipeline Databricks.
  • README avec procédure de démarrage, schéma du flux, limites et destruction.

La POC a ensuite été détruite avec Terraform pour éviter tout coût résiduel.