Konfigurowanie logowania OAuth2 identyfikatora entra firmy Microsoft
Ważny
Usługa Azure HDInsight w usłudze AKS została wycofana 31 stycznia 2025 r. Dowiedz się więcej z tym ogłoszeniem.
Aby uniknąć nagłego kończenia obciążeń, należy przeprowadzić migrację obciążeń do usługi Microsoft Fabric lub równoważnego produktu platformy Azure.
Ważny
Ta funkcja jest obecnie dostępna w wersji zapoznawczej. Dodatkowe warunki użytkowania platformy Microsoft Azure zawierają więcej warunków prawnych, które dotyczą funkcji platformy Azure znajdujących się w wersji beta, w wersji zapoznawczej lub w inny sposób jeszcze niewprowadzonych do ogólnej dostępności. Aby uzyskać informacje na temat tej konkretnej wersji zapoznawczej, zobacz informacje o wersji zapoznawczej Azure HDInsight na AKS. W przypadku pytań lub sugestii dotyczących funkcji, prześlij zgłoszenie na AskHDInsight z odpowiednimi szczegółami i śledź nas, aby otrzymywać nowe aktualizacje dotyczące społeczności Azure HDInsight.
W tym artykule opisano, jak umożliwić użytkownikom korzystanie z konta Microsoft Entra ("konto służbowe Microsoft") w celu zalogowania się do serwera Apache Superset.
Poniższa konfiguracja umożliwia użytkownikom automatyczne tworzenie kont Superset przy użyciu logowania Microsoft Entra. Grupy platformy Azure można automatycznie mapować na role Superset, co umożliwia kontrolę nad tym, kto może uzyskiwać dostęp do Superset oraz jakie uprawnienia są przydzielane.
Utwórz jednostkę usługi Entra firmy Microsoft. Kroki tworzenia identyfikatora Entra firmy Microsoft zostały opisane tutaj.
Na potrzeby testowania ustaw adres URL przekierowania na:
http://localhost:8088/oauth-authorized/azure
Utwórz następujące sekrety w składnicy kluczy.
Tajna nazwa Opis sekret klienta Klucz tajny usługi/aplikacji używany do logowania użytkownika. Zezwól tożsamości zarządzanej AKS (
$MANAGED_IDENTITY_RESOURCE
) na pobieranie i wyświetlanie tajemnic z Key Vault.Włącz autoryzację dostawcy sekretów Key Vault dla klastra. Aby uzyskać więcej informacji, zobacz tutaj .
az aks enable-addons --addons azure-keyvault-secrets-provider --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP_NAME
Przygotuj dostawcę tajemnic, aby umożliwić dostęp do sekretu podmiotu usługi z maszyn Superset. Aby uzyskać więcej informacji, zobacz tutaj.
Zaktualizuj plik YAML-a:
-
{{MSI_CLIENT_ID}}
— identyfikator klienta dla tożsamości zarządzanej przypisanej do klastra Superset ($MANAGED_IDENTITY_RESOURCE
). -
{{KEY_VAULT_NAME}}
— nazwa Azure Key Vault zawierająca tajemnice. -
{{KEY_VAULT_TENANT_ID}}
— identyfikator GUID dzierżawy platformy Azure, w której znajduje się Azure 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
-
Zastosuj klasę SecretProviderClass do klastra.
kubectl apply -f superset_secretproviderclass.yaml
Dodaj do konfiguracji Superset.
Zaktualizuj w konfiguracji:
-
{{AZURE_TENANT}}
— dzierżawa, do której logują się użytkownicy. -
{{SERVICE_PRINCIPAL_APPLICATION_ID}}
— identyfikator aplikacji/klienta jednostki usługi utworzonej w kroku 1. -
{{VALID_DOMAINS}}
— lista dozwolonych domen dla adresów e-mail użytkowników.
-
Przenieś ponownie nadzbiór
helm repo update
helm upgrade --install --values values.yaml superset superset/superset