Habilitar a federação de identidades de carga de trabalho para ações do GitHub

A federação de tokens Databricks OAuth, também conhecida como OpenID Connect (OIDC), permite que as suas cargas de trabalho automáticas que correm fora de Databricks acedam de forma segura a Databricks sem a necessidade de credenciais do Databricks. Consulte Autenticar o acesso ao Azure Databricks usando a federação de tokens OAuth.

Para habilitar a federação de identidades de carga de trabalho para ações do GitHub:

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

Depois de habilitar a federação de identidades 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 identidades para cargas de trabalho. Para obter instruções, consulte Configurar uma política de federação da entidade 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 sub declaração (assunto) do seu token. O padrão é Branch. O Databricks recomenda usar o Environment, que pode ser ativado ao definir o atributo environment no seu ficheiro YAML das ações do GitHub. Consulte Implantando 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 Ações do GitHub.
  • Audiências: O Databricks recomenda definir isso para sua ID de conta do Azure Databricks. Se omitido, o ID da conta é usado por padrão.
  • Reivindicação de assunto: (Opcional) A declaração JWT que contém o valor de identidade da carga de trabalho (sub) do token OIDC. Para o GitHub, deixe o campo como sub, que codifica o repositório, ramificação, tag, solicitação pull/merge ou ambiente que disparou o fluxo de trabalho. Para autenticar como um fluxo de trabalho reutilizável em vez do repositório que chama, consulte Autenticar 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 de ações do GitHub

Em seguida, configure o arquivo YAML de ações do GitHub. Defina as seguintes variáveis de ambiente:

  • DATABRICKS_AUTH_TYPE: github-oidc
  • DATABRICKS_HOST: URL do espaço de trabalho do Databricks
  • DATABRICKS_CLIENT_ID: O identificador da entidade de serviço (aplicação)
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 sub reclamação identifica o repositório que chama. Para autenticar como um workflow reutilizável, e não como o repositório que o chama, defina subject_claim para job_workflow_ref na política de federação. Qualquer equipa pode invocar o fluxo de trabalho reutilizável, mas só o próprio fluxo de trabalho reutilizável se autentica 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 sujeito. Defina subject para a referência do seu ficheiro 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 ficheiros YAML GitHub Actions

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

O exemplo seguinte mostra um ficheiro de fluxo de trabalho reutilizável (.github/workflows/deploy.yml no repositório de fluxos de trabalho partilhados):

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 seguinte mostra um fluxo de trabalho de chamada em qualquer repositório que utilize 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

Define permissions: id-token: write o fluxo de trabalho de chamadas, não o fluxo de trabalho reutilizável. GitHub só inclui a reivindicação job_workflow_ref no token OIDC quando id-token: write é concedida no fluxo de trabalho de chamada.