Os Tokens de Acesso Pessoal (PATs) são uma maneira conveniente de acessar serviços como o Azure Databricks ou o Azure DevOps sem precisar fazer login com sua senha. Hoje, muitos clientes usam tokens PAT do Azure DevOps como credenciais do Git para repositórios remotos em pastas Git do Databricks (anteriormente Repos). Infelizmente, o uso de tokens PAT tem algumas desvantagens. No Azure DevOps, os tokens PAT não podem ser emitidos para entidades de serviço e identidades gerenciadas, o que significa que os clientes recorrem a uma conta de serviço ou mesmo à identidade de um usuário. Além disso, a vida útil máxima dos tokens PAT é frequentemente de dias, semanas ou até meses. Embora sua rotação (o processo de atualização dos tokens de forma que os mais antigos não possam mais ser usados) possa ser governadoisso significa que um token vazado com uma vida útil longa pode representar um risco significativo. Uma alternativa mais segura é acessar os recursos do Azure DevOps usando um token de acesso do Microsoft Entra ID (antigo Azure Lively Listing).
Dos documentos da Microsoft:
Como os PATs são simplesmente tokens portadores, ou seja, sequências de tokens que representam o nome de usuário e a senha de um usuário, eles são incrivelmente arriscados de usar, pois podem facilmente cair nas mãos da pessoa errada. Os tokens Microsoft Entra expiram a cada hora (…), o que limita o fator de risco geral quando vazados.1) Ao considerar o acesso aos repositórios do Azure DevOps Git vinculados às suas pastas do Databricks Git, você não precisa mais depender de PATs. Agora, você pode usar tokens de acesso do Microsoft Entra ID, que têm controles mais rígidos em torno da rotação e expiração de tokens.
Neste weblog, aprenderemos como usar um token de acesso Entra ID como uma credencial Git em pastas Git do Databricks para fortalecer a postura de segurança ao extrair repositórios hospedados no Azure DevOps.
Pré-requisitos | Criar Principal de Serviço
Para começar, você precisa de uma identidade gerenciada ou principal de serviço. Se você não tiver uma, siga este documento: Registre um aplicativo Microsoft Entra e crie uma entidade de serviço. No closing, você terá um principal de serviço que poderá usar. Observe que neste cenário nenhum URI de redirecionamento é necessário, então você pode deixar esse elemento de formulário em branco. Certifique-se de criar um segredo e anote-o, junto com o ID do principal do serviço. (As etapas a seguir mostram como usar um principal de serviço como mecanismo de autenticação, mas as mesmas etapas também se aplicam a uma identidade gerenciada.)
Este processo pressupõe que você tenha um projeto do Azure DevOps configurado com um repositório Git que você gostaria de vincular a uma pasta Git do Databricks.
Etapa 1 | Conceda permissões de leitor ao principal do serviço em seu projeto
DevOps do UnderAzure Configurações do projeto > Permissões > Leitores adicione seu principal serviço.
Garantir que o nível de acesso seja suficiente para a operação necessária em Configurações da organização > Usuários.
Etapa 2 | Conceder permissões necessárias ao principal do serviço no Databricks
Se você usar o Unity Catalog, abra outra aba do navegador e acesse o console da sua conta do Databricks e adicione a entidade de serviço à sua conta.
Agora, gere um segredo OAuth para autenticar na API do Databricks (usando a CLI) e copie-o em algum lugar seguro.
Por fim, conceda ao usuário principal do serviço permissões no seu espaço de trabalho.
Etapa 3 | Use a CLI para criar o Entra ID Token e armazená-lo na credencial Git do Databricks
Você usará o Azure e o Databricks CLI para esta etapa. Para autenticar no Databricks, você precisa de um perfil de configuração (.databrickscfg) configurado com o token OAuth que acabamos de criar, a URL do seu espaço de trabalho e uma ID principal do serviço. Sua atualização para .databrickscfg deve ser algo como isto:
(DEFAULT)
host = https://.azuredatabricks.web/
client_id =
client_secret = Para registrar o principal do serviço com o AzureCLI, usamos o segredo que criamos anteriormente. O script solicita um token de acesso Entra ID com escopo para o Azure DevOps (indicado pelo UUID 499b84ac-1321-427f-aa17-267ca6975798), então configura uma credencial Git com o Databricks CLI e a usa para configurar nossa nova pasta Git:
#!/bin/bash
# Immediate consumer for required inputs and assign to variables
learn -p "Enter Service Principal ID: " service_principal_id
learn -p "Enter Tenant ID: " tenant_id
learn -p "Enter Service Principal Secret: " service_principal_secret
learn -p "Enter Service Principal Title: " service_principal_name
learn -p "Enter your Azure DevOps Group identify: " devops_organization
learn -p "Enter your Azure DevOps undertaking identify: " devops_project
learn -p "Enter your Azure DevOps repository identify: " devops_repo
#Login to Azure because the service principal
az login --allow-no-subscriptions --service-principal -u $service_principal_id -p $service_principal_secret --tenant $tenant_id
#Because the service principal, request an EntraID entry token scoped to Azure DevOps.
ENTRA_ID_TOKEN=$(az account get-access-token --resource "499b84ac-1321-427f-aa17-267ca6975798" --query "accessToken" --output tsv)
#Use the entry token as a substitute of a PAT to create a Git credential in Databricks with the service principal's identify as git username.
#This assumes you will have already setup the Databricks CLI .databrickscfg file with workspace, client_id, and client_secret
databricks git-credentials create azureDevOpsServices --personal-access-token $ENTRA_ID_TOKEN --git-username $service_principal_name
#Create a brand new Databricks repository utilizing the service principal identify because the consumer identify
databricks repos create https://$service_principal_name@dev.azure.com/$devops_organization/$devops_project/_git/$devops_repoResumo | O que vem a seguir?
Agora você aprendeu como gerar tokens de acesso do Microsoft Entra ID com escopo para o Azure DevOps e armazená-los como uma credencial do Databricks Git em vez de um token do DevOps PAT. Como o token de acesso do MS Entra ID tem vida curta, seu pipeline deve atualizar a credencial do Git usando o Databricks git-credentials replace e pode então disparar um pull chamando o Databricks repos replace. Como esse processo apenas mostra a configuração de credenciais, medidas de segurança adicionais geralmente são necessárias em um ambiente de produção, como armazenar o segredo do cliente principal do serviço e o token OAuth do Databricks em um armazenamento de segredos seguro, como o Azure Key Vault.
Ver Use segredos do Azure Key Vault em Azure Pipelines e Escopos secretos para mais detalhes.