Freigeben über


Aktivieren des Workload-Identitätsverbunds für GitLab CI/CD

Der OAuth-Tokenverbund von Databricks, auch als OpenID Connect (OIDC) bezeichnet, ermöglicht Es Ihren automatisierten Workloads, die außerhalb von Databricks ausgeführt werden, sicher auf Databricks zuzugreifen, ohne dass Databricks geheime Schlüssel erforderlich sind. Siehe Authentifizieren des Zugriffs auf Azure Databricks mithilfe des OAuth-Tokenverbunds.

So aktivieren Sie den Workload-Identitätsverbund für GitLab CI/CD:

  1. Erstellen einer Verbundrichtlinie
  2. Konfigurieren der GitLab-YAML-Datei

Nachdem Sie den Workload-Identitätsverbund aktiviert haben, rufen die Databricks-SDKs und die Databricks CLI Workload-Identitätstokens automatisch von GitLab CI/CD ab und tauschen sie gegen Databricks OAuth-Tokens aus.

Erstellen einer Verbundrichtlinie

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

  • Gruppe: Der Name Ihrer GitLab-Gruppe. Wenn die Projekt-URL beispielsweise lautet https://gitlab.com/databricks-inc/data-platform, lautet die Gruppe databricks-inc.
  • Projekt: Der Name des einzelnen GitLab-Projekts, das zugelassen werden soll, z data-platform. B. .
  • Bezugstyp: Die Art der Git-Referenz, die sub im Anspruch (Betreff) Ihres Tokens dargestellt wird. Dies kann Branch-, Tag- oder Merge-Anforderung sein.
  • Aussteller-URL: Die GitLab-Instanz-URL, die das OIDC-Token ausgibt.
  • Betreff: Eine Verkettung von Werten aus dem Auftragskontext.
  • Leserkreis: Der erwartete aud Wert im OIDC-Token. Konfigurieren Sie dies id_tokens: im Block Ihres Auftrags. Databricks empfiehlt, sie auf Ihre Azure Databricks-Konto-ID festzulegen.
  • Antragstelleranspruch: (Optional) Der JWT-Anspruch, der den Workload-Identitätswert (sub) aus dem OIDC-Token enthält. Lassen Sie für GitLab das Feld als sub, das das Projekt, die Verzweigung, das Tag oder die Zusammenführungsanforderung codiert, die die Pipeline ausgelöst hat.

Mit dem folgenden Cli-Befehl für Databricks wird beispielsweise eine Verbundrichtlinie für eine Numerische ID des Databricks-Dienstprinzipals erstellt:5581763342009999

databricks account service-principal-federation-policy create 5581763342009999 --json '{
  "oidc_policy": {
	"issuer": "https://gitlab.com/example-group",
	"audiences": [
  	  "a2222dd9-33f6-455z-8888-999fbbd77900"
	],
	"subject": "project_path:my-group/my-project:..."
  }
}'

Konfigurieren der GitLab-YAML-Datei

Ändern Sie als Nächstes die GitLab-Konfigurationsdatei. Wechseln Sie <databricks-account-id> zu Ihrer Azure Databricks-Konto-ID.

Speichern Sie zusätzlich zum Festlegen der folgenden Arbeitsbereichsumgebungsvariablen das Token in der DATABRICKS_OIDC_TOKEN Azure Databricks-Umgebungsvariable. Alternativ können Sie eine benutzerdefinierte Umgebungsvariable verwenden und festlegen DATABRICKS_OIDC_TOKEN_ENV.

  • DATABRICKS_AUTH_TYPE: env-oidc
  • DATABRICKS_HOST: Url des Databricks-Arbeitsbereichs
  • DATABRICKS_CLIENT_ID: Die Dienstprinzipal-ID (Anwendung)
spec:
  inputs:
    # Specify your Databricks account ID, workspace hostname, and service principal OAuth client ID.
    databricks-account-id:
    databricks-host:
    databricks-client-id:
    # See https://docs.gitlab.com/ci/inputs/#define-input-parameters-with-specinputs for more on pipeline input variables.
---
stages:
  - my_script_using_wif

variables:
  DATABRICKS_AUTH_TYPE: env-oidc
  DATABRICKS_HOST: $[[ inputs.databricks-host ]]
  DATABRICKS_CLIENT_ID: $[[ inputs.databricks-client-id ]]

my_script_using_wif:
  id_tokens:
    DATABRICKS_OIDC_TOKEN:
      aud: $[[ inputs.databricks-account-id ]]
  stage: my_script_using_wif
  image: ubuntu:latest
  before_script:
    - apt-get update -y
    - apt-get install -y curl unzip
    - curl -fsSL https://raw.githubusercontent.com/databricks/setup-cli/main/install.sh | sh
  script:
    - databricks current-user me