Aller au contenu principal
Dernière mise à jour le

Configurez une politique de fédération

La fédération de jetons OAuth Databricks vous permet d'accéder en toute sécurité aux APIs Databricks en utilisant des jetons de votre fournisseur d'identité (IdP). Pour activer la fédération de jetons OAuth, vous devez configurer une politique de fédération, soit à l'échelle du compte Databricks, soit pour les workloads.

Cette page décrit comment créer et configurer une stratégie de fédération de jetons OAuth.

Fédération d'identité Workload​

La fédération d'identités des Workloads permet à vos Workloads automatisés s'exécutant en dehors de Databricks d'accéder aux APIs Databricks sans nécessiter de secrets Databricks. Les administrateurs de compte peuvent configurer la fédération d'identités des Workloads à l'aide d'une politique de fédération de Service Principal.

Une politique de fédération de Service Principal est associée à un Service Principal de votre compte Databricks et spécifie :

  • Le fournisseur d'identité (ou émetteur) auprès duquel le Service Principal peut s'authentifier.
  • L'identité de la charge de travail (ou sujet) qui est autorisée à s'authentifier en tant que Service Principal Databricks.

Par exemple, étant donné la politique de fédération de Service Principal suivante pour une charge de travail GitHub Actions :

  • Émetteur : https://token.actions.githubusercontent.com
  • Audiences : https://github.com/my-github-org
  • Objet : repo:my-github-org/my-repo:environment:prod

Vous pouvez utiliser ce corps JWT pour vous authentifier auprès de Databricks :

JSON
{
  "iss": "https://token.actions.githubusercontent.com",
  "aud": "https://github.com/my-github-org",
  "sub": "repo:my-github-org/my-repo:environment:prod"
}

Configurer une politique de fédération de service principal​

Les administrateurs de compte peuvent configurer une politique de fédération de Service Principal à l'aide du CLI Databricks ou de l'API Databricks. Vous pouvez créer un maximum de 20 politiques de fédération de Service Principal par Service Principal Databricks.

Pour configurer une stratégie de fédération de Service Principal, vous devez spécifier les éléments suivants :

  • URL de l'émetteur : une URL HTTPS qui identifie le fournisseur d'identité de la charge de travail, spécifiée dans la revendication iss des jetons d'identité de la charge de travail.

  • **Objet :** L'identifiant unique de la charge de travail dans l'environnement d'exécution de la charge de travail. Si non spécifié, le default est sub.

  • Audiences : Le destinataire prévu du jeton, spécifié dans la revendication d’audience aud. Le jeton correspond si son audience correspond à au moins une audience de la politique. S'il n'est pas spécifié, l'ID de votre compte Databricks est utilisé par default.

  • Revendication de sujet : (Facultatif) Spécifie la revendication de jeton qui contient l'identité de la charge de travail (également appelée le sujet) du jeton. Si non défini, Databricks utilise sub par default. Databricks recommande de conserver la revendication par default sub pour la fédération d'identité de charge de travail. Ne choisissez une revendication différente que si sub n'est pas un identificateur de sujet approprié ou stable, ce qui est rare. Pour plus de détails, consultez Exemple de politiques de fédération de Service Principal.

  • Validation de la signature du jeton : (Facultatif) Les clés publiques, ou leur URL, au format JSON Web Key Sets (JWKS) utilisées pour valider les signatures de jeton. JWKS JSON prend en charge jusqu'à 5 clés. Si votre fournisseur d'identité en publie davantage, utilisez un URI JWKS à la place.

    Si non spécifié, Databricks récupère les clés à partir de l'Endpoint connu de l'émetteur, ce qui est l'approche recommandée. Votre fournisseur d'identité doit servir les métadonnées du fournisseur OpenID à <issuer-url>/.well-known/openid-configuration qui incluent un jwks_uri spécifiant l'emplacement des clés publiques utilisées pour vérifier les signatures de jetons.

  1. En tant qu'administrateur de compte, connectez-vous à la console de compte Databricks à l'adresse https://accounts.cloud.databricks.com.
  2. Cliquez sur **Gestion des utilisateurs**.
  3. Accédez à l’onglet Service principals .
  4. Sélectionnez le service principal pour lequel créer la politique.
  5. Accédez à l'onglet Identifiants et secrets .
  6. Sous l'onglet Federation policies tab, cliquez sur Créer une politique .
  7. Sélectionnez un fournisseur d'identifiants fédéré et configurez les champs correspondants.
  8. Cliquez sur Créer une politique .

Exemple de politiques de fédération de Service Principal Databricks​

Le tableau suivant présente des exemples de politiques de fédération de service principal et le corps JWT correspondant.

Pour connaître les étapes de configuration complètes permettant d’activer la fédération d’identité de charge de travail pour certains de ces fournisseurs d’identité courants, consultez Activer la fédération d’identité de charge de travail dans CI/CD.

Outil

Politique de fédération

Exemple de jeton correspondant.

GitHub Actions

Émetteur : https://token.actions.githubusercontent.com
Audience : https://github.com/<github-org>
Objet : repo:<github-org>/<repo>:environment:prod

{
"iss": "https://token.actions.githubusercontent.com",
"aud": "https://github.com/<github-org>",
"sub": "repo:<github-org>/<repo>:environment:prod"
}

Kubernetes

Émetteur : https://kubernetes.default.svc
Audience : https://kubernetes.default.svc
Objet : system:serviceaccount:namespace:serviceaccountname
JWKS JSON : {"keys":[{"kty":"rsa","e":"AQAB","use":"sig","kid":"<key-id>","alg":"RS256","n":"uPUViFv..."}]}

{
"iss": "https://kubernetes.default.svc",
"aud": ["https://kubernetes.default.svc"],
"sub": "system:serviceaccount:namespace:serviceaccountname"
}

Azure DevOps

Émetteur : https://vstoken.dev.azure.com/<org_id>
Audience : api://AzureADTokenExchange
Objet : sc://my-org/my-project/my-connection

{
"iss": "https://vstoken.dev.azure.com/<org_id>",
"aud": "api://AzureADTokenExchange",
"sub": "sc://my-org/my-project/my-connection"
}

GitLab

Émetteur : https://gitlab.example.com
Audience : https://gitlab.example.com
Objet : project_path:my-group/my-project:...

{
"iss": "https://gitlab.example.com",
"aud": "https://gitlab.example.com",
"sub": "project_path:my-group/my-project:..."
}

CircleCI

Émetteur : https://oidc.circleci.com/org/<org_id>
Audience : <org_id>
Objet : 7cc1d11b-46c8-4eb2-9482-4c56a910c7ce
Revendication de sujet : oidc.circleci.com/project-id

{
"iss": "https://oidc.circleci.com/org/<org_id>",
"aud": "<org_id>",
"oidc.circleci.com/project-id": "7cc1d11b-46c8-4eb2-9482-4c56a910c7ce"
}

Fédération d’identités sortante AWS IAM

Émetteur : https://<uuid>.tokens.sts.global.api.aws (URL d'émetteur spécifique au compte)
Audience : databricks (ou toute valeur convenue transmise à GetWebIdentityToken)
Objet : arn:aws:iam::<account>:role/<role-name>

{
"iss": "https://<uuid>.tokens.sts.global.api.aws",
"aud": ["databricks"],
"sub": "arn:aws:iam::123456789012:role/my-workload-role"
}

Outil

Politique de fédération

Exemple de jeton correspondant.

GitHub Actions

Émetteur : https://token.actions.githubusercontent.com
Audience : https://github.com/<github-org>
Objet : repo:<github-org>/<repo>:environment:prod

{
"iss": "https://token.actions.githubusercontent.com",
"aud": "https://github.com/<github-org>",
"sub": "repo:<github-org>/<repo>:environment:prod"
}

Kubernetes

Émetteur : https://kubernetes.default.svc
Audience : https://kubernetes.default.svc
Objet : system:serviceaccount:namespace:serviceaccountname
JWKS JSON : {"keys":[{"kty":"rsa","e":"AQAB","use":"sig","kid":"<key-id>","alg":"RS256","n":"uPUViFv..."}]}

{
"iss": "https://kubernetes.default.svc",
"aud": ["https://kubernetes.default.svc"],
"sub": "system:serviceaccount:namespace:serviceaccountname"
}

Azure DevOps

Émetteur : https://vstoken.dev.azure.com/<org_id>
Audience : api://AzureADTokenExchange
Objet : sc://my-org/my-project/my-connection

{
"iss": "https://vstoken.dev.azure.com/<org_id>",
"aud": "api://AzureADTokenExchange",
"sub": "sc://my-org/my-project/my-connection"
}

GitLab

Émetteur : https://gitlab.example.com
Audience : https://gitlab.example.com
Objet : project_path:my-group/my-project:...

{
"iss": "https://gitlab.example.com",
"aud": "https://gitlab.example.com",
"sub": "project_path:my-group/my-project:..."
}

CircleCI

Émetteur : https://oidc.circleci.com/org/<org_id>
Audience : <org_id>
Objet : 7cc1d11b-46c8-4eb2-9482-4c56a910c7ce
Revendication de sujet : oidc.circleci.com/project-id

{
"iss": "https://oidc.circleci.com/org/<org_id>",
"aud": "<org_id>",
"oidc.circleci.com/project-id": "7cc1d11b-46c8-4eb2-9482-4c56a910c7ce"
}

Fédération d’identités sortante AWS IAM

Émetteur : https://<uuid>.tokens.sts.global.api.aws (URL d'émetteur spécifique au compte)
Audience : databricks (ou toute valeur convenue transmise à GetWebIdentityToken)
Objet : arn:aws:iam::<account>:role/<role-name>

{
"iss": "https://<uuid>.tokens.sts.global.api.aws",
"aud": ["databricks"],
"sub": "arn:aws:iam::123456789012:role/my-workload-role"
}

remarque

Pour la fédération d'identités sortantes AWS IAM, la revendication sub dans le jeton est l'ARN du rôle IAM de la charge de travail appelante (par exemple, le rôle d'exécution Lambda, le rôle de tâche ECS ou le rôle d'instance EC2).

Bonnes pratiques pour les politiques de fédération de service principal​

Chaque Service Principal prend en charge un maximum de 20 stratégies de fédération. Suivez ces directives pour éviter d'atteindre cette limite.

Mapper une identité externe par service principal​

Créez un Service Principal dédié pour chaque identité de charge de travail externe distincte. Plusieurs politiques de fédération sur un seul Service Principal ne sont appropriées que lorsque la même identité logique s'authentifie par le biais de différents fournisseurs d'identité. Par exemple, une charge de travail qui s'exécute à la fois dans GitHub Actions et Azure DevOps nécessite deux politiques, une par fournisseur, sur le même Service Principal.

N'utilisez pas plusieurs politiques pour mapper différentes charges de travail (telles que des pods Kubernetes séparés par région) à un seul Service Principal. Créez plutôt un Service Principal distinct pour chaque charge de travail. Cela préserve l'attribution du audit Logs et vous permet de révoquer l'accès pour une charge de travail sans affecter les autres.

Rationaliser les autorisations avec des groupes​

Lorsque plusieurs Service Principal ont besoin des mêmes autorisations, ajoutez-les en tant que membres d'un groupe Databricks et attribuez les autorisations au groupe. Voir les meilleures pratiques d'identité.

Utilisez la propriété subject_claim pour les revendications alternatives​

Par default, Databricks utilise la revendication sub du jeton d'identité pour identifier la charge de travail. Si votre fournisseur d'identité n'utilise pas la revendication sub comme identifiant de charge de travail stable, définissez la propriété subject_claim sur le nom de revendication utilisé par votre fournisseur. Pour un exemple, voir la configuration CircleCI dans Exemple de politiques de fédération de Service Principal Databricks.

Fédération de jetons à l'échelle du compte​

Les administrateurs de compte peuvent configurer la fédération de jetons OAuth dans le compte Databricks à l'aide d'une politique de fédération de compte. Une politique de fédération de compte permet à tous les utilisateurs et Service Principals de votre compte Databricks d'accéder aux APIs Databricks à l'aide de jetons de votre fournisseur d'identité. Une politique de fédération de compte spécifie :

  • Le fournisseur d'identité ou l'émetteur auprès duquel Databricks acceptera les jetons.
  • Les critères pour mapper un jeton à l'utilisateur Databricks ou au service principal correspondant.

Par exemple, étant donné une politique de fédération avec les champs suivants :

  • Émetteur : https://idp.mycompany.com/oidc
  • Audiences : databricks
  • Revendication de sujet : sub

Utilisez ce corps JWT pour vous authentifier auprès de Databricks en tant que username@mycompany.com:

JSON
{
  "iss": "https://idp.mycompany.com/oidc",
  "aud": "databricks",
  "sub": "username@mycompany.com"
}

Configurer une politique de fédération de compte​

Les administrateurs de compte peuvent configurer une politique de fédération de compte à l'aide de l'interface utilisateur de Databricks, de la CLI Databricks ou de l'API REST Databricks. Vous pouvez spécifier un maximum de 20 politiques de fédération de compte dans votre compte Databricks.

Pour configurer une stratégie de fédération de compte, vous devez spécifier les éléments suivants :

  • URL de l'émetteur : une URL HTTPS qui identifie votre fournisseur d'identité, spécifiée dans la revendication iss de vos jetons.

  • Audiences : Le destinataire prévu du jeton, spécifié dans la revendication d’audience aud. Le jeton correspond si son audience correspond à au moins une audience de la politique. S'il n'est pas spécifié, l'ID de votre compte Databricks est utilisé par default.

  • Revendication du sujet : La revendication de jeton qui contient le nom d'utilisateur Databricks de l'utilisateur pour lequel le jeton a été émis. Si non spécifié, le default est sub.

  • Validation de la signature du jeton : (Facultatif) Les clés publiques, ou leur URL, au format JSON Web Key Sets (JWKS) utilisées pour valider les signatures de jeton. JWKS JSON prend en charge jusqu'à 5 clés. Si votre fournisseur d'identité en publie davantage, utilisez un URI JWKS à la place.

    Si non spécifié, Databricks récupère les clés à partir de l'Endpoint connu de l'émetteur, ce qui est l'approche recommandée. Votre fournisseur d'identité doit servir les métadonnées du fournisseur OpenID à <issuer-url>/.well-known/openid-configuration qui incluent un jwks_uri spécifiant l'emplacement des clés publiques utilisées pour vérifier les signatures de jetons.

important

Pour la fédération à l'échelle du compte, enregistrez uniquement les IdP qui sont entièrement managés et approuvés par votre organisation, tels que l'IdP de votre propre entreprise. Ne configurez pas de fédération à l'échelle du compte avec des fournisseurs d'identité externes que vous ne contrôlez pas, tels que ceux gérés par des clients ou des Partenaires.

  1. En tant qu'administrateur de compte, connectez-vous à la console de compte Databricks à l'adresse https://accounts.cloud.databricks.com.
  2. Cliquez sur Sécurité et accédez à l'onglet tab .
  3. Sous Politiques de fédération , cliquez sur Créer une politique .
  4. Entrez l’URL de l’émetteur, les audiences, la revendication de l’objet et la validation facultative de la signature du jeton.
  5. Cliquez sur Créer une politique .

Exemples de politiques de fédération de comptes​

Le tableau suivant fournit des exemples de politiques de fédération de compte et le corps de jeton JWT correspondant.

Politique de fédération

Exemple de jeton correspondant.

Émetteur : https://idp.mycompany.com/oidc
Audience : 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d

{
"iss": "https://idp.mycompany.com/oidc",
"aud": "2ff814a6-3304-4ab8-85cb-cd0e6f879c1d",
"sub": "username@mycompany.com"
}

Émetteur : https://idp.mycompany.com/oidc
Audience : 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d
Revendication de sujet : preferred_username

{
"iss": "https://idp.mycompany.com/oidc",
"aud": ["2ff814a6-3304-4ab8-85cb-cd0e6f879c1d", "other-audience"],
"preferred_username": "username@mycompany.com",
"sub": "some-other-ignored-value"
}

Émetteur : https://idp.mycompany.com/oidc
Audience : 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d
JWKS JSON : {"keys":[{"kty":"RSA","e":"AQAB","use":"sig","kid":"<key-id>","alg":"RS256","n":"uPUViFv..."}]}

{
"iss": "https://idp.mycompany.com/oidc",
"aud": "2ff814a6-3304-4ab8-85cb-cd0e6f879c1d",
"sub": "username@mycompany.com"
}
(signature vérifiée à l'aide de la clé publique dans la politique)

Émetteur : https://idp.mycompany.com/oidc
Audience : 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d
URI JWKS : https://idp.mycompany.com/jwks.json

{
"iss": "https://idp.mycompany.com/oidc",
"aud": "2ff814a6-3304-4ab8-85cb-cd0e6f879c1d",
"sub": "username@mycompany.com"
}
(signature vérifiée à l'aide de la clé publique récupérée de jwks_uri)

Politique de fédération

Exemple de jeton correspondant.

Émetteur : https://idp.mycompany.com/oidc
Audience : 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d

{
"iss": "https://idp.mycompany.com/oidc",
"aud": "2ff814a6-3304-4ab8-85cb-cd0e6f879c1d",
"sub": "username@mycompany.com"
}

Émetteur : https://idp.mycompany.com/oidc
Audience : 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d
Revendication de sujet : preferred_username

{
"iss": "https://idp.mycompany.com/oidc",
"aud": ["2ff814a6-3304-4ab8-85cb-cd0e6f879c1d", "other-audience"],
"preferred_username": "username@mycompany.com",
"sub": "some-other-ignored-value"
}

Émetteur : https://idp.mycompany.com/oidc
Audience : 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d
JWKS JSON : {"keys":[{"kty":"RSA","e":"AQAB","use":"sig","kid":"<key-id>","alg":"RS256","n":"uPUViFv..."}]}

{
"iss": "https://idp.mycompany.com/oidc",
"aud": "2ff814a6-3304-4ab8-85cb-cd0e6f879c1d",
"sub": "username@mycompany.com"
}
(signature vérifiée à l'aide de la clé publique dans la politique)

Émetteur : https://idp.mycompany.com/oidc
Audience : 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d
URI JWKS : https://idp.mycompany.com/jwks.json

{
"iss": "https://idp.mycompany.com/oidc",
"aud": "2ff814a6-3304-4ab8-85cb-cd0e6f879c1d",
"sub": "username@mycompany.com"
}
(signature vérifiée à l'aide de la clé publique récupérée de jwks_uri)

Étapes suivantes​

Après avoir configuré une stratégie de fédération pour votre compte :

  • Configurez votre fournisseur d'identité (IdP) pour générer des jetons que vos utilisateurs peuvent échanger avec Databricks. Reportez-vous à la documentation de votre IdP pour les détails de configuration. Pour obtenir des instructions sur l'activation de la fédération d'identités de charge de travail avec des fournisseurs d'identité courants, consultez Activer la fédération d'identités de charge de travail en CI/CD.
  • Utilisez un JWT de votre IdP pour accéder à l'API Databricks en l'échangeant d'abord contre un jeton Databricks OAuth. Incluez le jeton Databricks OAuth dans l'en-tête Bearer: de votre appel d'API pour terminer la requête. Le JWT doit être valide et signé à l'aide des algorithmes RS256 ou ES256. Pour plus de détails sur la mise en œuvre, consultez Authentification avec un jeton de fournisseur d'identité.
Sur cette page