Aktivieren der Workload-Identitätsverbund für GitHub-Aktionen

Databricks OAuth Token Federation, auch bekannt als OpenID Connect (OIDC), ermöglicht es Ihren automatisierten Workloads, die außerhalb von Databricks ausgeführt werden, sicher auf Databricks ohne Databricks-Geheimnisse zuzugreifen. Siehe Authentifizieren des Zugriffs auf Azure Databricks mithilfe des OAuth-Tokenverbunds.

So aktivieren Sie den Workload-Identitätsverbund für GitHub-Aktionen:

1. Erstellen einer Verbundrichtlinie
2. Konfigurieren der YaML-Datei für GitHub-Aktionen

Nachdem Sie den Workload-Identitätsverbund aktiviert haben, rufen die Databricks-SDKs und die Databricks CLI Automatisch Workload-Identitätstoken von GitHub ab und tauschen sie für OAuth-Token von Databricks aus.

Erstellen einer Verbundrichtlinie

Erstellen Sie zunächst eine Workload-Identitätsverbundrichtlinie. Anweisungen finden Sie unter Konfigurieren einer Dienstprinzipalverbundrichtlinie. Legen Sie für GitHub die folgenden Werte für die Richtlinie fest:

• Organisation: Der Name Ihrer Github-Organisation. Wenn ihre Repository-URL beispielsweise lautet https://github.com/databricks-inc/data-platform, lautet die Organisation databricks-inc.
• Repository: Der Name des einzelnen Repository, das freigegeben werden soll, wie z. B. data-platform.
• Entitätstyp: Die Art der GitHub-Entität, die sub im Anspruch (Betreff) Ihres Tokens dargestellt wird. Der Standardwert ist Branch. Databricks empfiehlt die Verwendung von Environment, die Sie aktivieren können, indem Sie das environment Attribut in Ihrer GitHub Actions YAML-Datei festlegen. Siehe Bereitstellen in einer bestimmten Umgebung.
• Aussteller-URL:https://token.actions.githubusercontent.com
• Betreff: Eine Zeichenfolge, die durch Verketten von Werten aus dem GitHub Actions-Auftragskontext gebildet wird.
• Zielgruppe: Databricks empfiehlt, dass dies auf Ihre Azure Databricks-Konto-ID eingestellt wird. Wenn sie weggelassen wird, wird die Konto-ID standardmäßig verwendet.
• Antragstelleranspruch: (Optional) Der JWT-Anspruch, der den Workload-Identitätswert (sub) aus dem OIDC-Token enthält. Lassen Sie für GitHub das Feld als sub, welches das Repository, den Branch, den Tag, die Pull-/Merge-Request oder die Umgebung codiert, die den Workflow ausgelöst hat. Informationen zur Authentifizierung als wiederverwendbarer Workflow anstelle des aufrufenden Repositorys finden Sie unter Authentifizieren mithilfe eines wiederverwendbaren Workflows.

Beispielsweise erstellt der folgende Databricks CLI-Befehl eine Verbundrichtlinie für eine Organisation mit dem Namen my-org und eine Numerische ID des Databricks-Dienstprinzipals von 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"
  }
}'

Konfigurieren der YaML-Datei für GitHub-Aktionen

Konfigurieren Sie als Nächstes die YAML-Datei für GitHub Actions. Legen Sie die folgenden Umgebungsvariablen fest:

• DATABRICKS_AUTH_TYPE: github-oidc
• DATABRICKS_HOST: Url des Databricks-Arbeitsbereichs
• DATABRICKS_CLIENT_ID: Die Dienstprinzipal-ID (Anwendung)

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

Authentifizieren mithilfe eines wiederverwendbaren Workflows

Standardmäßig identifiziert der sub Anspruch das aufrufende Repository. Um sich als wiederverwendbarer Workflow und nicht als aufrufendes Repository zu authentifizieren, setzen Sie subject_claim zu job_workflow_ref in die Verbundrichtlinie. Jedes Team kann den wiederverwendbaren Workflow aufrufen, aber nur der wiederverwendbare Workflow selbst authentifiziert sich bei Databricks.

Erstellen einer Verbundrichtlinie

Erstellen Sie eine Verbundrichtlinie, die job_workflow_ref als Anspruch verwendet. Legen Sie subject als Verweis auf Ihre wiederverwendbare Workflowdatei fest.

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

Konfigurieren Sie die GitHub Actions YAML-Dateien

Erstellen Sie einen wiederverwendbaren Workflow, der sich mit Azure Databricks authentifiziert, und einen aufrufenden Workflow in jedem Repository, das ihn aufruft.

Das folgende Beispiel zeigt eine wiederverwendbare Workflowdatei (.github/workflows/deploy.yml im Repository für freigegebene Workflows):

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

Das folgende Beispiel zeigt einen aufrufenden Workflow in jedem Repository, das den wiederverwendbaren Workflow verwendet:

on: workflow_dispatch

permissions:
  id-token: write
  contents: read

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