Поделиться через

Настройка имени входа OAuth2 идентификатора Microsoft Entra

  • Статья

Внимание

Эта функция в настоящее время доступна для предварительного ознакомления. Дополнительные условия использования для предварительных версий Microsoft Azure включают более юридические термины, применимые к функциям Azure, которые находятся в бета-версии, в предварительной версии или в противном случае еще не выпущены в общую доступность. Сведения об этой конкретной предварительной версии см. в статье Azure HDInsight в предварительной версии AKS. Для вопросов или предложений функций отправьте запрос на AskHDInsight с подробными сведениями и следуйте за нами для получения дополнительных обновлений в сообществе Azure HDInsight.

В этой статье описывается, как разрешить пользователям использовать учетную запись Microsoft Entra ("рабочая или учебная учетная запись Майкрософт") для входа в Apache Superset.

Следующая конфигурация позволяет пользователям автоматически создавать учетные записи суперустановок при использовании имени входа Microsoft Entra. Группы Azure можно автоматически сопоставить с ролями суперустановок, которые позволяют управлять доступом к суперсети и разрешениям.

  1. Создайте субъект-службу Microsoft Entra. Здесь описаны шаги по созданию идентификатора Microsoft Entra.

    Для тестирования задайте URL-адрес перенаправления следующим образом: http://localhost:8088/oauth-authorized/azure

  2. Создайте следующие секреты в хранилище ключей.

    Имя секрета Description
    client-secret Секрет субъекта-службы или приложения, используемый для входа пользователя.

  3. Разрешите управляемому удостоверению$MANAGED_IDENTITY_RESOURCE AKS получать и перечислять секреты из Key Vault.

  4. Включите имя входа поставщика секретов Key Vault для кластера. Для получения дополнительных сведений см. здесь.

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

  5. Подготовьте поставщика секретов, чтобы разрешить доступ к секрету субъекта-службы на компьютерах суперустановки. Для получения дополнительных сведений см. здесь.

    Обновление в yaml:

    • {{MSI_CLIENT_ID}} — идентификатор клиента управляемого удостоверения, назначенного кластеру супермножества ($MANAGED_IDENTITY_RESOURCE).
    • {{KEY_VAULT_NAME}} — Имя Azure Key Vault, содержащего секреты.
    • {{KEY_VAULT_TENANT_ID}} — guid идентификатора клиента Azure, где находится хранилище ключей.

    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. Примените SecretProviderClass к кластеру.

    kubectl apply -f superset_secretproviderclass.yaml

  7. Добавьте в конфигурацию суперустановки.

    Обновление в конфигурации:

    • {{AZURE_TENANT}} — Клиент, в который входят пользователи.
    • {{SERVICE_PRINCIPAL_APPLICATION_ID}} — Идентификатор клиента или приложения субъекта-службы, созданного на шаге 1.
    • {{VALID_DOMAINS}} — список разрешенных доменов для адресов электронной почты пользователей.

    Ознакомьтесь с примером кода.

Повторное развертывание супермножества

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

Next Steps