Partager via


Activer la fédération des identités de charge de travail pour GitLab CI/CD

La fédération de jetons OAuth Databricks, également appelée OpenID Connect (OIDC), permet à vos charges de travail automatisées s’exécutant en dehors de Databricks d’accéder en toute sécurité à Databricks sans avoir besoin de secrets Databricks. Consultez Authentifier l’accès à Azure Databricks à l’aide de la fédération de jeton OAuth.

Pour activer la fédération des identités de charge de travail pour GitLab CI/CD :

  1. Créer une stratégie de fédération
  2. Configurer le fichier YAML GitLab

Après avoir activé la fédération des identités de charge de travail, les sdk Databricks et l’interface CLI Databricks récupèrent automatiquement les jetons d’identité de charge de travail à partir de GitLab CI/CD et les échangent pour les jetons OAuth Databricks.

Créer une stratégie de fédération

Tout d’abord, créez une stratégie de fédération d’identité de charge de travail. Pour obtenir des instructions, consultez Configurer une stratégie de fédération de principal de service. Pour GitLab CI/CD, définissez les valeurs suivantes :

  • Groupe: Nom de votre groupe GitLab. Par exemple, si l’URL de votre projet est https://gitlab.com/databricks-inc/data-platform, le groupe est databricks-inc.
  • Projet: Nom du projet GitLab unique à autoriser, par data-platformexemple .
  • Type de référence : Type de référence Git représenté dans la sub revendication (objet) de votre jeton. Il peut s’agir d’une branche, d’une balise ou d’une requête de fusion.
  • URL de l’émetteur : URL de l’instance GitLab qui émet le jeton OIDC.
  • Objet: Concaténation des valeurs extraites du contexte de travail.
  • Public: Valeur attendue aud dans le jeton OIDC. Configurez-le dans le bloc de id_tokens: votre travail. Databricks recommande de le définir sur votre ID de compte Azure Databricks.
  • Revendication d’objet : (facultatif) Revendication JWT qui contient la valeur d’identité de charge de travail (sub) du jeton OIDC. Pour GitLab, laissez le champ en tant que sub, qui encode le projet, la branche, la balise ou la demande de fusion qui a déclenché le pipeline.

Par exemple, la commande CLI Databricks suivante crée une stratégie de fédération pour un ID numérique numérique du principal de service Databricks :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:..."
  }
}'

Configurer le fichier YAML GitLab

Ensuite, modifiez le fichier de configuration GitLab. Passez <databricks-account-id> à votre ID de compte Azure Databricks.

Outre la définition des variables d’environnement d’espace de travail suivantes, stockez le jeton dans la DATABRICKS_OIDC_TOKEN variable d’environnement Azure Databricks. Vous pouvez également utiliser une variable d’environnement personnalisée et définir DATABRICKS_OIDC_TOKEN_ENV.

  • DATABRICKS_AUTH_TYPE: env-oidc
  • DATABRICKS_HOST: URL de votre espace de travail Databricks
  • DATABRICKS_CLIENT_ID: ID du principal de service (application)
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