Workload-identiteitsfederatie inschakelen voor GitHub Actions

Met Databricks OAuth-tokenfederatie, ook wel bekend als OpenID Connect (OIDC), kunnen uw geautomatiseerde workloads die buiten Databricks worden uitgevoerd, veilig toegang krijgen tot Databricks zonder Databricks-geheimen. Zie Verificatietoegang tot Azure Databricks met behulp van OAuth-tokenfederatie.

De workloadidentiteitsfederatie inschakelen voor GitHub Actions:

  1. Een federatiebeleid maken
  2. Het YAML-bestand van GitHub Actions configureren

Nadat u workloadidentiteitsfederatie hebt ingeschakeld, halen de Databricks SDK's en de Databricks CLI automatisch workloadidentiteitstokens op uit GitHub en wisselen ze uit voor Databricks OAuth-tokens.

Een federatiebeleid maken

Maak eerst een beleid voor federatie van workload-identiteiten. Zie Een federatiebeleid voor de service-principal configureren voor instructies. Stel voor GitHub de volgende waarden in voor het beleid:

  • Organisatie: De naam van uw GitHub-organisatie. Als de URL van uw opslagplaats bijvoorbeeld https://github.com/databricks-inc/data-platform is, dan is de organisatie databricks-inc.
  • Opslagplaats: De naam van de enkele opslagplaats die moet worden toegestaan, zoals data-platform.
  • Entiteitstype: Het type GitHub-entiteit dat wordt weergegeven in de sub claim (onderwerp) van uw token. De standaardwaarde is Branch. Databricks raadt u aan omgeving te gebruiken, die u kunt inschakelen door het environment kenmerk in te stellen in uw YAML-bestand van GitHub Actions. Zie Implementeren in een specifieke omgeving.
  • URL van verlener:https://token.actions.githubusercontent.com
  • Onderwerp: Een tekenreeks die wordt gevormd door het samenvoegen van waarden uit de context van de GitHub Actions-taak.
  • Publiek: Databricks raadt u aan dit in te stellen op uw Azure Databricks-account-id. Als u dit weglaat, wordt de account-id standaard gebruikt.
  • Onderwerpclaim: (Optioneel) De JWT-claim die de waarde van de workloadidentiteit (sub) van het OIDC-token bevat. Voor GitHub laat u het veld staan als sub, waarmee de opslagplaats, vertakking, tag, pull/merge-aanvraag of omgeving die de werkstroom heeft geactiveerd, codeert. Zie Authenticatie met een herbruikbare werkstroom in plaats van via de aanroepende opslagplaats.

Met de volgende Databricks CLI-opdracht maakt u bijvoorbeeld een federatiebeleid voor een organisatie met de naam my-org en een numerieke id van een Databricks-service-principal van 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"
  }
}'

Het YAML-bestand van GitHub Actions configureren

Configureer vervolgens het YAML-bestand van GitHub Actions. Stel de volgende omgevingsvariabelen in:

  • DATABRICKS_AUTH_TYPE: github-oidc
  • DATABRICKS_HOST: De URL van uw Databricks-werkruimte
  • DATABRICKS_CLIENT_ID: De ID van de service-principal (toepassing)
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

Verifiƫren met behulp van een herbruikbare werkstroom

Standaard identificeert de claim sub de aanroepende opslagplaats. Stel subject_claim in op job_workflow_ref in het federatiebeleid om te authenticeren als een herbruikbare werkstroom in plaats van de aanroepende repository. Elk team kan de herbruikbare werkstroom aanroepen, maar alleen de herbruikbare werkstroom zelf wordt geverifieerd met Databricks.

Een federatiebeleid maken

Maak een federatiebeleid met job_workflow_ref als subject-claim. Stel subject in op de ref van het bestand van de herbruikbare workflow.

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

Configureer de GitHub Actions YAML-bestanden

Maak een herbruikbare werkstroom die wordt geverifieerd met Azure Databricks en een aanroepende werkstroom in een opslagplaats die deze aanroept.

In het volgende voorbeeld ziet u een herbruikbaar werkstroombestand (.github/workflows/deploy.yml in de opslagplaats voor gedeelde werkstromen):

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

In het volgende voorbeeld ziet u een aanroepende werkstroom in een opslagplaats die gebruikmaakt van de herbruikbare werkstroom:

on: workflow_dispatch

permissions:
  id-token: write
  contents: read

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

Note

Stel permissions: id-token: write in op de aanroepende werkstroom, niet op de herbruikbare werkstroom. GitHub bevat alleen de claim job_workflow_ref in het OIDC-token wanneer id-token: write wordt verleend aan de aanroepende werkstroom.