Aller au contenu principal
Dernière mise à jour le

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

La fédération de jetons Databricks OAuth, également appelée OpenID Connect (OIDC), permet à vos charges de travail automatisées s'exécutant en dehors de Databricks d'accéder en toute sécurité à Databricks sans les secrets Databricks. Voir Authentifier l'accès à Databricks à l'aide de la fédération de jetons OAuth.

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

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

Après avoir activé la fédération d’identité de charge de travail, les SDK Databricks et la CLI Databricks récupèrent automatiquement les jetons d’identité de charge de travail de GitHub et les échangent contre des jetons OAuth Databricks.

Créer une politique de fédération​

Tout d'abord, créez une politique de fédération d'identités de charge de travail. Pour obtenir des instructions, consultez Configurer une politique de fédération de Service Principal. Pour GitHub, définissez les valeurs suivantes pour la politique :

  • Organization : Le nom de votre organisation GitHub. Par exemple, si l’URL de votre repository est https://github.com/databricks-inc/data-platform, alors l’organisation est databricks-inc.
  • Repository : le nom du repository unique à autoriser, tel que data-platform.
  • Type d'entité : Le type d'entité GitHub représenté dans la revendication sub (sujet) de votre jeton. Le default est Branch . Databricks recommande d'utiliser Environment , que vous pouvez activer en définissant l'attribut environment dans votre fichier YAML GitHub Actions. Voir Déploiement vers un environnement spécifique.
  • URL de l'émetteur : https://token.actions.githubusercontent.com
  • Subject : une chaîne formée en concaténant les valeurs du contexte de job GitHub Actions. Le format requis dépend de la revendication GitHub sub de votre repository. Consultez la remarque suivante.
  • Publics : Databricks recommande de le définir sur votre ID de compte Databricks. S'il est omis, l'ID de compte est utilisé par default.
  • Revendication de sujet : (Facultatif) La revendication JWT qui contient la valeur de l'identité de charge de travail (sub) du jeton OIDC. Pour GitHub, laissez le champ tel quel (sub), qui encode le repository, la branch, le tag, la pull/merge request ou l'environnement qui a déclenché le workflow. Pour vous authentifier en tant que workflow réutilisable plutôt que le repository appelant, voir S'authentifier à l'aide d'un workflow réutilisable.
remarque

Databricks met en correspondance le champ Subject exact avec la revendication sub du jeton, et le format sub de GitHub dépend de la date de création du repository. Les repository créés, renommés ou transférés à compter du 15 juillet 2026 incluent des ID d’organisation et de repository numériques, tels que repo:octo-org@123456/octo-repo@456789:environment:prod. Les repository plus anciens utilisent repo:<org>/<repo>:environment:prod, sauf s’ils optent pour le format immuable.

Pour trouver le sub exact de votre repository, consultez la page À propos du renforcement de la sécurité avec OpenID Connect. Le format immuable n’est pas disponible sur le serveur GitHub Enterprise.

Par exemple, la commande Databricks CLI suivante crée une règle de fédération pour une organisation nommée my-org et un ID numérique de service principal Databricks de 5581763342009999. L’exemple d’objet utilise le format basé uniquement sur le nom pour un repository créé avant le 15 juillet 2026 :

Bash
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"
  }
}'

Configurez le fichier YAML de GitHub Actions​

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

  • DATABRICKS_AUTH_TYPE: github-oidc
  • DATABRICKS_HOST: Votre URL de workspace Databricks
  • DATABRICKS_CLIENT_ID: L’ID de l’application du service principal
YAML
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

Authentification à l’aide d’un workflow réutilisable​

By default, la revendication sub identifie le repository appelant. Pour vous authentifier en tant que workflow réutilisable plutôt que le repository appelant, définissez subject_claim sur job_workflow_ref dans la politique de fédération. N'importe quelle équipe peut invoquer le workflow réutilisable, mais seul le workflow réutilisable lui-même s'authentifie auprès de Databricks.

Créer une politique de fédération​

Créer une politique de fédération en utilisant job_workflow_ref comme revendication de sujet. Définissez subject sur la référence de votre fichier de workflow réutilisable :

Bash
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"
  }
}'

Configurez les fichiers YAML GitHub Actions​

Créez un workflow réutilisable qui s'authentifie auprès de Databricks, et un workflow appelant dans n'importe quel repository qui l'invoque.

L'exemple suivant montre un fichier de workflow réutilisable (.github/workflows/deploy.yml dans le repository de workflows partagés) :

YAML
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 workflow d'appel dans n'importe quel repository qui utilise le workflow réutilisable :

YAML
on: workflow_dispatch

permissions:
  id-token: write
  contents: read

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

Définissez permissions: id-token: write sur le workflow appelant, et non sur le workflow réutilisable. GitHub inclut uniquement la revendication job_workflow_ref dans le jeton OIDC lorsque id-token: write est accordé sur le workflow appelant.

Sur cette page