Configurer la connexion OAuth2 pour Microsoft Entra ID

Important

Azure HDInsight sur AKS a été mis hors service le 31 janvier 2025. En savoir plus avec cette annonce.

Vous devez migrer vos charges de travail vers Microsoft Fabric ou un produit Azure équivalent pour éviter l’arrêt brusque de vos charges de travail.

Important

Cette fonctionnalité est actuellement en préversion. Les Conditions d’utilisation supplémentaires pour les préversions Microsoft Azure incluent des termes juridiques supplémentaires qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou qui ne sont pas encore publiées en disponibilité générale. Pour plus d’informations sur cette préversion spécifique, consultez informations sur Azure HDInsight sur AKS en préversion. Pour des questions ou des suggestions de fonctionnalités, envoyez une demande sur AskHDInsight avec les détails et suivez-nous pour plus de mises à jour sur Communauté Azure HDInsight.

Cet article explique comment autoriser les utilisateurs à utiliser leur compte Microsoft Entra (« compte professionnel ou scolaire Microsoft ») pour se connecter à Apache Superset.

La configuration suivante permet aux utilisateurs de créer automatiquement des comptes Superset quand ils utilisent leur connexion Microsoft Entra. Les groupes Azure peuvent être mappés automatiquement aux rôles Superset, ce qui permet de contrôler qui peut accéder à Superset et quelles autorisations sont données.

1. Créez un objet principal de service Microsoft Entra. Les étapes de création de l’ID Microsoft Entra sont décrites ici.

   Pour les tests, définissez l’URL de redirection sur : http://localhost:8088/oauth-authorized/azure

2. Créez les secrets suivants dans un coffre-fort de clés.

   Nom du secret	Description
   client-secret	Principal de service/secret d’application utilisé pour la connexion utilisateur.

3. Autoriser votre identité managée AKS ($MANAGED_IDENTITY_RESOURCE) à obtenir et répertorier les secrets stockés dans le Key Vault.

4. Activez la connexion du fournisseur de secrets Key Vault pour votre cluster. Pour plus d’informations, consultez ici.

   az aks enable-addons --addons azure-keyvault-secrets-provider --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP_NAME
   

5. Préparez un fournisseur de secrets pour permettre à votre secret de principal de service d'être accessible à partir des machines Superset. Pour plus d’informations, consultez ici.

   Mise à jour dans le yaml :

   • {{MSI_CLIENT_ID}} - ID client de l’identité managée affectée au cluster Superset ($MANAGED_IDENTITY_RESOURCE).
   • {{KEY_VAULT_NAME}} : nom du coffre de clés Azure contenant les secrets.
   • {{KEY_VAULT_TENANT_ID}} - Identifiant guid du tenant Azure où se trouve le Key Vault.

   superset_secretproviderclass.yaml :

   # This is a SecretProviderClass example using aad-pod-identity to access the key vault
   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
    name: azure-secret-provider
   spec:
   provider: azure
   parameters:
    useVMManagedIdentity: "true" 
    userAssignedIdentityID: "{{MSI_CLIENT_ID}}"
    usePodIdentity: "false"               # Set to true for using aad-pod-identity to access your key vault
    keyvaultName: "{{KEY_VAULT_NAME}}"    # Set to the name of your key vault
    cloudName: ""                         # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud
    objects: |
      array:
        - |
          objectName: client-secret
          objectType: secret
    tenantId: "{{KEY_VAULT_TENANT_ID}}"  # The tenant ID of the key vault
   secretObjects:                             
   - secretName: azure-kv-secrets
     type: Opaque
     data:
     - key: AZURE_SECRET
      objectName: client-secret
   

6. Appliquez SecretProviderClass à votre cluster.

   kubectl apply -f superset_secretproviderclass.yaml
   

7. Ajoutez à votre configuration Superset.

   Mise à jour dans la configuration :

   • {{AZURE_TENANT}} : locataire auquel les utilisateurs se connectent.
   • {{SERVICE_PRINCIPAL_APPLICATION_ID}} : ID client/application du principal de service que vous avez créé à l’étape 1.
   • {{VALID_DOMAINS}} - liste autorisée de domaines pour les adresses e-mail des utilisateurs.

   Reportez-vous à l'exemple de code .

Redéployer Superset

helm repo update
helm upgrade --install --values values.yaml superset superset/superset

Étapes suivantes

• contrôle d’accès en fonction du rôle