Configurar o logon OAuth2 do Microsoft Entra ID

Este artigo descreve como permitir que os usuários usem a respectiva conta do Microsoft Entra ("conta corporativa ou de estudante da Microsoft") para entrar no Apache Superset.

A configuração a seguir permite que as contas do Superset sejam criadas automaticamente quando os usuários usam o respectivo logon do Microsoft Entra. Os grupos do Azure podem ser mapeados automaticamente para funções do Superset, o que permite o controle sobre quem pode acessar o Superset e quais permissões são concedidas.

1. Crie uma entidade de serviço do Microsoft Entra. As etapas para criar o Microsoft Entra ID estão descritas aqui.

   Para fins de teste, defina a URL de redirecionamento como: http://localhost:8088/oauth-authorized/azure

2. Crie os segredos a seguir em um cofre de chaves.

   Nome do segredo	Descrição
   client-secret	Segredo da entidade de serviço/aplicativo usado para o logon do usuário.

3. Permita que sua identidade gerenciada pelo AKS ($MANAGED_IDENTITY_RESOURCE) obtenha e liste os segredos do Key Vault.

4. Habilite o logon do provedor de segredos do Key Vault para o cluster. Para mais informações, consulte aqui.

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

5. Prepare um provedor de segredos a fim de permitir que o segredo da entidade de serviço seja acessível pelas máquinas Superset. Para mais informações, consulte aqui.

   Faça a atualização no YAML:

   • {{MSI_CLIENT_ID}} – A ID do cliente da identidade gerenciada atribuída ao cluster Superset ($MANAGED_IDENTITY_RESOURCE).
   • {{KEY_VAULT_NAME}} – O nome do Azure Key Vault que contém os segredos.
   • {{KEY_VAULT_TENANT_ID}} – O GUID do identificador do locatário do Azure em que o cofre de chaves está.

   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. Aplique a SecretProviderClass ao cluster.

   kubectl apply -f superset_secretproviderclass.yaml
   

7. Faça a adição à configuração do Superset.

   Faça a atualização na configuração:

   • {{AZURE_TENANT}} – O locatário em que os usuários fazem logon.
   • {{SERVICE_PRINCIPAL_APPLICATION_ID}} – A ID do cliente/aplicativo da entidade de serviço que você criou na etapa 1.
   • {{VALID_DOMAINS}} – Uma lista de domínios permitidos para endereços de email de usuários.

   Confira o código de exemplo.

Reimplantação do Superset

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

Próximas etapas

• Controle de acesso baseado em função