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

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

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

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

Depois de habilitar a federação de identidade de carga de trabalho, os SDKs do Databricks e a CLI do Databricks buscam automaticamente tokens de identidade de carga de trabalho do GitHub e os trocam por tokens OAuth do Databricks.

Criar uma política de federação

Primeiro, crie uma política de federação de identidade de carga de trabalho. Para obter instruções, consulte Como configurar uma política de federação para um principal de serviço. Para o GitHub, defina os seguintes valores para a política:

  • Organização: O nome da sua organização do Github. Por exemplo, se a URL do repositório 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 do GitHub representada na declaração sub (assunto) do token. O padrão é Branch. O Databricks recomenda o uso do Ambiente, que você pode habilitar definindo o environment atributo no arquivo YAML do GitHub Actions. Consulte a seção Implantação em um ambiente específico.
  • URL do emissor:https://token.actions.githubusercontent.com
  • Assunto: Uma cadeia de caracteres formada pela concatenação de valores do contexto de trabalho do GitHub Actions.
  • Público: O Databricks recomenda definir isso para sua ID da conta do Azure Databricks. Se omitida, a ID da conta será usada por padrão.
  • Declaração do assunto: (Opcional) A declaração JWT que contém o valor da identidade da carga de trabalho (sub) do token OIDC. Para o GitHub, deixe o campo como sub, que codifica o repositório, o branch, a marca, a solicitação de pull/mesclagem ou o ambiente que disparou o fluxo de trabalho. Para autenticar como um fluxo de trabalho reutilizável em vez do repositório de chamadas, consulte Authenticate usando um fluxo de trabalho reutilizável.

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 do principal de serviço Databricks de 5581763342009999:

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: a URL do seu workspace Databricks
  • DATABRICKS_CLIENT_ID: O ID do principal de serviço (aplicativo)
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

Autenticar usando um fluxo de trabalho reutilizável

Por padrão, a declaração sub identifica o repositório de chamadas. Para autenticar como um fluxo de trabalho reutilizável em vez de como o repositório de chamadas, defina subject_claim para job_workflow_ref na política de federação. Qualquer equipe pode invocar o fluxo de trabalho reutilizável, mas apenas o próprio fluxo de trabalho reutilizável é autenticado com o Databricks.

Criar uma política de federação

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

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

Configurar os arquivos YAML do GitHub Actions

Crie um fluxo de trabalho reutilizável que se autentique com Azure 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 fluxos de trabalho compartilhados):

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 usa o fluxo de trabalho reutilizável:

on: workflow_dispatch

permissions:
  id-token: write
  contents: read

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

Note

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