Abilitare la federazione delle identità del carico di lavoro per GitHub Actions

La federazione dei token OAuth di Databricks, nota anche come OpenID Connect (OIDC), consente ai carichi di lavoro automatizzati in esecuzione all'esterno di Databricks di accedere in modo sicuro a Databricks senza segreti di Databricks. Vedere Autenticare l'accesso ad Azure Databricks usando la federazione dei token OAuth.

Per abilitare la federazione delle identità del carico di lavoro per GitHub Actions:

1. Creare un criterio federativo
2. Configurare il file YAML di GitHub Actions

Dopo aver abilitato la federazione dell'identità del carico di lavoro, gli SDK di Databricks e l'interfaccia della riga di comando di Databricks recuperano automaticamente i token di identità del carico di lavoro da GitHub e li scambiano per i token OAuth di Databricks.

Creare una politica di federazione

Creare prima di tutto un criterio di federazione dell'identità del carico di lavoro. Per le istruzioni, consulta Configurare un criterio di federazione dell'entità servizio. Per GitHub, impostare i valori seguenti per i criteri:

• Organizzazione: Nome dell'organizzazione Github. Ad esempio, se l'URL del repository è https://github.com/databricks-inc/data-platform, l'organizzazione è databricks-inc.
• Deposito: Il nome del singolo deposito da consentire, come ad esempio data-platform.
• Tipo di entità: Tipo di entità GitHub rappresentata nell'attestazione sub (oggetto) del token. Il valore predefinito è Branch. Databricks consiglia di usare Environment, che è possibile abilitare impostando l'attributo environment nel file YAML di GitHub Actions. Vedere Distribuzione in un ambiente specifico.
• URL emittente:https://token.actions.githubusercontent.com
• Oggetto: Stringa formata dalla concatenazione di valori dal contesto del processo gitHub Actions.
• Pubblico: Databricks consiglia di impostare questa opzione sull'ID dell'account Azure Databricks. Se omesso, l'ID account viene usato per impostazione predefinita.
• Attestazione del soggetto: (facoltativo) Attestazione JWT che contiene il valore dell'identità del carico di lavoro (sub) dal token OIDC. Per GitHub lasciare il campo come sub, che codifica il repository, il ramo, il tag, la richiesta pull/merge o l'ambiente che ha attivato il flusso di lavoro. Per eseguire l'autenticazione come flusso di lavoro riutilizzabile anziché come repository chiamante, vedere Eseguire l'autenticazione usando un flusso di lavoro riutilizzabile.

Ad esempio, il comando della CLI Databricks seguente crea una politica di federazione per un'organizzazione chiamata my-org e un ID numerico per un principal del servizio Databricks di 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"
  }
}'

Configurare il file YAML di GitHub Actions

Configurare quindi il file YAML di GitHub Actions. Impostare le seguenti variabili di ambiente:

• DATABRICKS_AUTH_TYPE: github-oidc
• DATABRICKS_HOST: URL dell'area di lavoro di Databricks
• DATABRICKS_CLIENT_ID: ID del principale servizio (applicazione)

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

Eseguire l'autenticazione usando un flusso di lavoro riutilizzabile

Per impostazione predefinita, il claim sub identifica il repository invocante. Per eseguire l'autenticazione come workflow riutilizzabile anziché come repository chiamante, impostare subject_claim su job_workflow_ref nella politica di federazione. Qualsiasi team può richiamare il flusso di lavoro riutilizzabile, ma solo il flusso di lavoro riutilizzabile stesso esegue l'autenticazione con Databricks.

Creare una politica di federazione

Creare un criterio federativo usando job_workflow_ref come attestazione dell'oggetto. Imposta subject sul riferimento del file di flusso di lavoro riutilizzabile:

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

Configurare i file YAML di GitHub Actions

Creare un flusso di lavoro riutilizzabile che esegue l'autenticazione con Azure Databricks e un flusso di lavoro chiamante in qualsiasi repository che lo richiama.

L'esempio seguente mostra un file del flusso di lavoro riutilizzabile (.github/workflows/deploy.yml nel repository dei flussi di lavoro condivisi):

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'esempio seguente mostra un workflow di invocazione in qualsiasi repository che utilizza il flusso di lavoro riutilizzabile.

on: workflow_dispatch

permissions:
  id-token: write
  contents: read

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