Configurez la connexion OAuth2 de Microsoft Entra ID

Remarque

Nous allons mettre hors service Azure HDInsight sur AKS le 31 janvier 2025. Avant le 31 janvier 2025, vous devrez migrer vos charges de travail vers Microsoft Fabric ou un produit Azure équivalent afin d’éviter leur arrêt brutal. Les clusters restants de votre abonnement seront arrêtés et supprimés de l’hôte.

Seul le support de base est disponible jusqu’à la date de mise hors service.

Important

Cette fonctionnalité est disponible actuellement en mode Aperçu. Les Conditions d’utilisation supplémentaires pour les préversions de Microsoft Azure contiennent davantage de conditions légales qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou ne se trouvant pas encore en disponibilité générale. Pour plus d’informations sur cette préversion spécifique, consultez les Informations sur la préversion d’Azure HDInsight sur AKS. Pour toute question ou pour des suggestions à propos des fonctionnalités, veuillez envoyer vos requêtes et leurs détails sur AskHDInsight, et suivez-nous sur la Communauté Azure HDInsight pour plus de mises à jour.

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 principal de service Microsoft Entra. Les étapes de création de Microsoft Entra ID 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 de clés.

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

3. Autorisez votre identité managée AKS ($MANAGED_IDENTITY_RESOURCE) à obtenir et à répertorier les secrets à partir du coffre de clés.

4. Activez la connexion du fournisseur de secrets Key Vault pour votre cluster. Vous pourrez trouver plus d’informations 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 principal de service d’être accessible à partir des machines Superset. Vous pourrez trouver plus d’informations ici.

   Mise à jour dans le yaml :

   • {{MSI_CLIENT_ID}} - L’ID client de l’identité managée attribuée au cluster Superset ($MANAGED_IDENTITY_RESOURCE).
   • {{KEY_VAULT_NAME}} - Le nom de Azure Key Vault contenant les secrets.
   • {{KEY_VAULT_TENANT_ID}} - Le Guid d’identificateur du locataire Azure où se trouve le coffre de clés.

   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 la SecretProviderClass à votre cluster.

   kubectl apply -f superset_secretproviderclass.yaml
   

7. Ajoutez à votre configuration Superset.

   Mise à jour dans la configuration :

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

   Reportez-vous à l’exemple de code.

Redéployez 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