Pular para o conteúdo principal
Última atualização em

Habilitar a federação de identidade de carga de trabalho para GitHub Actions

A federação de tokens OAuth do Databricks, também conhecida como OpenID Connect (OIDC), permite que suas cargas de trabalho automatizadas, executadas fora do Databricks, acessem o Databricks com segurança, sem a necessidade de segredos do Databricks. Consulte Autenticar o acesso ao Databricks usando a federação de tokens OAuth.

Para habilitar a federação de identidade de carga de trabalho para GitHub Actions:

  1. Crie uma política de federação
  2. Configurar o arquivo YAML do GitHub Actions

Depois que o senhor ativar a federação de identidade da carga de trabalho, os SDKs da Databricks e a CLI da Databricks buscarão automaticamente os tokens de identidade da carga de trabalho do GitHub e os trocarão por tokens OAuth da Databricks.

Crie uma política de federação​

Primeiro, crie uma política de federação de identidades de carga de trabalho. Para obter instruções, consulte Configurar uma política de federação de entidade de serviço. Para o GitHub, defina os seguintes valores para a política:

  • Organization: O nome da sua organização do GitHub. Por exemplo, se o URL do seu repository for https://github.com/databricks-inc/data-platform, a organização será databricks-inc.
  • repositório: O nome do repositório único a ser permitido, como data-platform.
  • Tipo de entidade: O tipo de entidade GitHub representada na reivindicação sub (assunto) de seus tokens. O site default é Branch . A Databricks recomenda o uso do Environment , que o senhor pode ativar definindo o atributo environment no arquivo YAML do GitHub Actions. Veja implantado em um ambiente específico.
  • URL do emissor: https://token.actions.githubusercontent.com
  • Subject: Uma string formada pela concatenação de valores do contexto de job do GitHub Actions. O formato obrigatório depende da reivindicação do GitHub sub do seu repository. Consulte a nota a seguir.
  • Audiences (Audiências): Databricks recomenda que o senhor defina essa opção como sua ID Databricks account . Se omitido, o ID account é usado por default.
  • Declaração do assunto: (Opcional) A declaração JWT que contém o valor da identidade da carga de trabalho (sub) dos tokens OIDC. Para o GitHub, deixe o campo como sub, que codifica o repositório, branch, tag, pull/merge request ou ambiente que acionou o fluxo de trabalho. Para autenticar como um fluxo de trabalho reutilizável em vez do repositório de chamada, consulte Autenticar usando um fluxo de trabalho reutilizável.
nota

O Databricks compara o Subject exatamente com a claim sub do token, e o formato do sub do GitHub depende de quando o repository foi criado. repository criados, renomeados ou transferidos em ou após 15 de julho de 2026 incluem IDs numéricos de organização e repository, como repo:octo-org@123456/octo-repo@456789:environment:prod. repository anteriores usam repo:<org>/<repo>:environment:prod, a menos que optem pelo formato imutável.

Para encontrar o sub exato do seu repository, consulte Sobre o endurecimento de segurança com o OpenID Connect. O formato imutável não está disponível no GitHub Enterprise Server.

Por exemplo, o seguinte comando da CLI do Databricks cria uma política de federação para uma organização chamada my-org e uma ID numérica de Service Principal do Databricks igual a 5581763342009999. O assunto de exemplo usa o formato somente de nome para um repository criado antes de 15 de julho de 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"
  }
}'

Configurar o arquivo YAML do GitHub Actions​

Em seguida, configure o arquivo YAML do GitHub Actions. Defina as seguintes variáveis de ambiente:

  • DATABRICKS_AUTH_TYPE: github-oidc
  • DATABRICKS_HOST: Seu URL Databricks workspace
  • DATABRICKS_CLIENT_ID: A ID da entidade de serviço (aplicativo)
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

Autentique usando um fluxo de trabalho reutilizável.​

Por default, a declaração sub identifica o repositório de chamada. Para autenticar como um fluxo de trabalho reutilizável em vez do repositório de chamada, defina subject_claim para job_workflow_ref na política de federação. Qualquer equipe pode invocar o fluxo de trabalho reutilizável, mas somente o próprio fluxo de trabalho reutilizável se autentica com o Databricks.

Crie uma política de federação​

Crie uma política de federação usando job_workflow_ref como a declaração de assunto. Defina subject como a referência do seu arquivo de fluxo de trabalho reutilizável:

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

Configure os arquivos YAML do GitHub Actions.​

Crie um fluxo de trabalho reutilizável que se autentique com o Databricks e um fluxo de trabalho de chamada em qualquer repositório que o invoque.

O exemplo a seguir mostra um arquivo de fluxo de trabalho reutilizável (.github/workflows/deploy.yml no repositório de fluxo de trabalho compartilhado):

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

O exemplo a seguir mostra um fluxo de trabalho de chamada em qualquer repositório que utilize o fluxo de trabalho reutilizável:

YAML
on: workflow_dispatch

permissions:
  id-token: write
  contents: read

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

Defina permissions: id-token: write no fluxo de trabalho de chamada, não no fluxo de trabalho reutilizável. GitHub inclui a declaração job_workflow_ref nos tokens OIDC apenas quando id-token: write é concedido no fluxo de trabalho de chamada.

Nesta página