Activer la fédération des identités de charge de travail pour GitHub Actions

La fédération de jetons OAuth de Databricks, également appelée OpenID Connect (OIDC), permet à vos charges de travail automatisées qui s’exécutent en dehors de Databricks d’accéder en toute sécurité à Databricks sans avoir besoin de propriétés secrètes de Databricks. Consultez Authentifier l’accès à Azure Databricks à l’aide de la fédération de jeton OAuth.

Pour activer la fédération des identités de charge de travail pour GitHub Actions :

  1. Créer une stratégie de fédération
  2. Configurer le fichier YAML GitHub Actions

Après avoir activé la fédération des identités de charge de travail, les sdk Databricks et l’interface CLI Databricks récupèrent automatiquement des jetons d’identité de charge de travail à partir de GitHub et les échangent pour les jetons OAuth Databricks.

Créer une stratégie de fédération

Tout d’abord, créez une stratégie de fédération d'identités de charges de travail. Pour obtenir des instructions, consultez Configurer une stratégie de fédération de principal de service. Pour GitHub, définissez les valeurs suivantes pour la stratégie :

  • Organisation : Le nom de votre organisation GitHub. Par exemple, si l’URL de votre dépôt est https://github.com/databricks-inc/data-platform, l’organisation est databricks-inc.
  • Dépôt: Nom du référentiel unique à autoriser, tel que data-platform.
  • Type d’entité : Type d’entité GitHub représentée dans la sub revendication (objet) de votre jeton. La valeur par défaut est Branch. Databricks recommande d’utiliser l’environnement, que vous pouvez activer en définissant l’attribut environment dans votre fichier YAML GitHub Actions. Consultez Déploiement sur un environnement spécifique.
  • URL de l’émetteur :https://token.actions.githubusercontent.com
  • Objet: Chaîne formée par concaténation de valeurs à partir du contexte de travail GitHub Actions. Le format requis dépend de la revendication GitHub sub de votre référentiel. Voir la note suivante.
  • Public: Databricks recommande de définir cette valeur sur votre ID de compte Azure Databricks. S’il est omis, l’ID de compte est utilisé par défaut.
  • Revendication de l’objet : (facultatif) Revendication JWT qui contient la valeur d’identité de charge de travail (sub) du jeton OIDC. Pour GitHub, laissez le champ en tant que sub, qui encode le référentiel, la branche, la balise, la demande de tirage/fusion ou l’environnement qui a déclenché le flux de travail. Pour s’authentifier en tant que flux de travail réutilisable plutôt que dans le référentiel appelant, consultez Authentifier à l’aide d’un flux de travail réutilisable.

Note

Azure Databricks compare exactement l’Objet à la revendication sub du jeton, et le format de sub GitHub dépend du moment où le référentiel a été créé. Les dépôts créés, renommés ou transférés à partir du 15 juillet 2026 incluent des identifiants numériques d’organisation et de dépôt, tels que repo:octo-org@123456/octo-repo@456789:environment:prod. Les dépôts plus anciens utilisent repo:<org>/<repo>:environment:prod, sauf s’ils optent pour le format immutable.

Pour trouver le sub exact de votre référentiel, consultez la section À propos du renforcement de la sécurité avec OpenID Connect. Le format immutable n'est pas disponible sur GitHub Enterprise Server.

Par exemple, la commande CLI de Databricks suivante crée une politique de fédération pour une organisation nommée my-org et un identifiant numérique de principal de service Databricks de 5581763342009999. Le sujet d’exemple utilise le format avec nom uniquement pour un dépôt créé avant le 15 juillet 2026 :

databricks account service-principal-federation-policy create 5581763342009999 --json '{
  "oidc_policy": {
	"issuer": "https://token.actions.githubusercontent.com",
	"audiences": [
  	  "a2222dd9-33f6-455z-8888-999fbbd77900"
	],
	"subject": "repo:my-github-org/my-repo:environment:prod"
  }
}'

Configurer le fichier YAML GitHub Actions

Ensuite, configurez le fichier YAML GitHub Actions. Définissez les variables d’environnement suivantes :

  • DATABRICKS_AUTH_TYPE : github-oidc
  • DATABRICKS_HOST: URL de votre espace de travail Databricks
  • DATABRICKS_CLIENT_ID : ID (d’application) du principal de service
name: GitHub Actions Demo
run-name: ${{ github.actor }} is testing out GitHub Actions 🚀
on: workflow_dispatch

permissions:
  id-token: write
  contents: read

jobs:
  my_script_using_wif:
    runs-on: ubuntu-latest
    environment: prod
    env:
      DATABRICKS_AUTH_TYPE: github-oidc
      DATABRICKS_HOST: https://my-workspace.cloud.databricks.com/
      DATABRICKS_CLIENT_ID: a1b2c3d4-ee42-1eet-1337-f00b44r

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Install Databricks CLI
        uses: databricks/setup-cli@main

      - name: Run Databricks CLI commands
        run: databricks current-user me

S’authentifier à l’aide d’un flux de travail réutilisable

Par défaut, la déclaration sub identifie le référentiel appelant. Pour s’authentifier en tant que flux de travail réutilisable plutôt que le référentiel appelant, définissez subject_claim sur job_workflow_ref dans la stratégie de fédération. Toute équipe peut appeler le flux de travail réutilisable, mais seul le workflow réutilisable s’authentifie auprès de Databricks.

Créer une stratégie de fédération

Créez une stratégie de fédération en utilisant job_workflow_ref comme revendication de sujet. Assignez subject à la référence de votre fichier de flux de travail réutilisable :

databricks account service-principal-federation-policy create 5581763342009999 --json '{
  "oidc_policy": {
    "issuer": "https://token.actions.githubusercontent.com",
    "audiences": [
      "a2222dd9-33f6-455z-8888-999fbbd77900"
    ],
    "subject": "my-github-org/shared-workflows/.github/workflows/deploy.yml@refs/heads/main",
    "subject_claim": "job_workflow_ref"
  }
}'

Configurer les fichiers YAML des Actions GitHub

Créez un flux de travail réutilisable qui s’authentifie avec Azure Databricks et un flux de travail appelant dans n’importe quel référentiel qui l’appelle.

L’exemple suivant montre un fichier de flux de travail réutilisable (.github/workflows/deploy.yml dans le référentiel de flux de travail partagé) :

on:
  workflow_call:

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      DATABRICKS_AUTH_TYPE: github-oidc
      DATABRICKS_HOST: https://my-workspace.cloud.databricks.com/
      DATABRICKS_CLIENT_ID: a1b2c3d4-ee42-1eet-1337-f00b44r

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Install Databricks CLI
        uses: databricks/setup-cli@main

      - name: Run Databricks CLI commands
        run: databricks current-user me

L'exemple suivant montre un exemple de processus d'appel dans tout référentiel exploitant le processus réutilisable :

on: workflow_dispatch

permissions:
  id-token: write
  contents: read

jobs:
  call-deploy:
    uses: my-github-org/shared-workflows/.github/workflows/deploy.yml@main

Note

Définissez permissions: id-token: write dans le flux de travail appelant, plutôt que dans le flux de travail réutilisable. GitHub inclut uniquement la revendication job_workflow_ref dans le jeton OIDC lorsque id-token: write est accordé au flux de travail appelant.

  • Dernière mise à jour :