Fundamental no universo do Big Data, o Data lake pode ser utilizado no Azure, entretanto, a correta configuração do serviço é primordial para utilizá-lo de maneira escalável e sustentável.

Neste artigo, te mostraremos como usar o Service Principal para realizar a autenticação entre o Databricks e o Data Lake, um dos principais caminhos para extrair o máximo de valor dessas ferramentas.

Um dos assuntos mais falados no universo de TI e de Big Data é a criação de Data Lake e a possibilidade de gerar valor para o negócio a partir de um local único de armazenamento de informações, por meio de ferramentas de processamento de dados como o Databricks (Spark “como serviço”).

No ambiente do Azure temos a oportunidade de entregar esse valor por meio da criação de um Data Lake utilizando o Azure Data Lake gen2 (ADLS) e processar gigabytes ou até petabytes utilizando uma arquitetura escalável com o Azure Databricks (ADB).

Ok. E como podemos conectar o Azure Databricks no ADLS gen2? Qual é a melhor prática? Como posso garantir a segurança do meu Data Lake?

Vamos começar entendendo melhor as ferramentas.

ADLS gen2 e ADB

• O ADLS gen2 é um “recurso” do Azure Storage Account que só pode ser ativado na criação da conta por meio da flag “hierarquical namespaces.
• O ADB é a distribuição da plataforma de solução da Databricks rodando com a infraestrutura Azure, isto é, todos os recursos são semelhantes a uma implementação padrão do Databricks, contudo, por ser ativado dentro da Azure, sua infraestrutura é criada dentro da sua conta (veja mais detalhes neste link).

E como uma se comunica com a outra?

Basicamente, existem duas formas de autenticação na qual o ADB pode se conectar com o ADLS:

1. Passthrough: Nesta forma o login de um usuário é enviado do ADB para o ADLS. É imprescindível que esse usuário tenha as permissões necessárias para conseguir acessar o serviço – lembre-se que as permissões no ADLS podem ser relacionada ao IAM (RBAC) e/ou ao ACL;
2. OAuth: Um “login de aplicação” é parametrizado no cluster ou seção do Databricks e enviado ao ADLS, de forma que todos os usuários do ADB que estiverem com essa configuração utilizarão estes mesmos parâmetros para acessar o ADLS.

Dessa forma, cada uma das opções possuem possibilidades diferentes de uso.
O Passthrough pode ser usado tanto em clusters standard como single-user quanto em clusters de alta concorrência para uso de times completos de dados, contudo, ele possui uma série de limitações.
Por exemplo: a impossibilidade de utilizar o ACL do ADB (que é diferente do ACL do ADLS) que permite o controle de permissões em objetos do recurso “data” – com “GRANTs” e “DENYs” (mais informações sobre as limitações, clique aqui) ou a autenticação do Azure Data Factory.

Já o OAuth possui menos limitações, porém, possui dois contratempos:

1. A sua configuração é bem mais complexa;
2. A gestão de “grupos” também é um pouco mais complicada, uma vez que estamos falando da autenticação de “apps” e não mais “pessoas”.

Entendendo o OAuth

Apesar de mais complexa, a conexão OAuth apresenta uma quantidade menor de limitações, vamos nos aprofundar um pouco nas formas que podemos utilizá-la, que basicamente são duas:

1. Autenticação via Token do ADLS: não recomendamos que use esse método, ainda mais em ambiente produtivo, uma vez que o acesso via token garante ao usuário acesso “ilimitado” ao ADLS
2. Via App ID: Registramos um app e uma senha no Azure Active Directory (AAD) e, através dessas configurações, parametrizamos o ADB para acessar o ADLS. Esse método possui uma séria limitação: ele não permite o uso de segurança ACL do ADLS (que permite segurança granular aos objetos do ADLS) direto pelo App ID porque ele não é identificado pelo ADLS , apenas segurança IAM (RBAC

Realizar a comunicação via App ID traz importantes limitações no aspecto de segurança do seu Data Lake. Felizmente existe uma forma de ainda utilizarmos essa autenticação e conseguirmos a segurança granular necessária: utilizando o Service Principal do App no acesso ao ADLS.

Ou seja, identificando o Service Principal na segurança do seu ADLS podemos fazer com que todos os usuários de um cluster do ADB utilizem ele respeitando regras de segurança (como impossibilitar edição de dados em determinadas camadas do Data Lake), sendo assim um recurso extremamente importante nas implementações de Data Lake com o ADLS e ADB.

Portanto, é possível utilizar o Service Principal de um App como um “grupo de usuários” para garantir o acesso granular controlado através do ACL do ADLS. A configuração dos parâmetros do Service Principal pode ser feita através de uma seção do Databricks ou até na configuração do cluster.

Configurando o Service Principal

Para facilitar seu dia a dia, trouxemos um passo a passo de como criar um App (criando automaticamente o Service Principal dele), configurar uma instância do Key-vault para ocultar informações sensíveis no ADB e utilizar o Service Principal na configuração de segurança do seu acesso OAuth – este passo-a-passo está focado na configuração do Service Principal por seção.

Precisa configurá-lo no cluster? Entre em contato com o time da Iteris para que possamos entender melhor como te ajudar????

Pré-requisitos:

• É necessário ter acesso de administração nos recursos do Azure para criação e configuração de todos os passos seguintes.
• Recomendamos um Workspace premium do Databricks (para configuração do Key-vault), apesar de não ser requisito para uso do Service Principal.
• Possuir o Storage Explorer instalado e atualizado (o download pode ser feito através deste link em “Baixar agora”)

Criando o App no Azure Active Directory

1. Acesse sua conta no portal do Azure e vá no Azure Active Directory

2. Acesse “Apps registration” no menu lateral e clique em “+ New Registration”

3. Entre com o nome que deseja para o app, por exemplo “databricks-users-test” e tenha certeza que a primeira opção esteja marcada em “Supported account types” (para isolar esse app ao seu tenant). Os demais campos são opcionais.
   

4. Após a criação do app, vá até a tela dele no AAD, entre em “Certificates & Secrets” e crie uma chave. Tenha atenção ao tempo de expiração, isto pode influenciar o funcionamento da autenticação e lembre-se de anotar o SECRET DO APP após a criação, precisaremos dele.

5. Após criar o secret, volte ao Overview do App e anote o Application (client) Id e o Directory (tenant) Id.

Criando o Key-vault e configurando os secrets necessários

1. Acesse o recurso do Key-Vault no seu portal do Azure.

2. Crie uma instância (lembre-se de tentar organizar o melhor possível os recursos do Azure utilizando nomes de acordo com as convenções, resource groups e subscriptions) de peferência na mesma região que o workspace do Databricks. Você também pode utilizar uma instância existente se for o caso, mas lembre-se dos parâmetros de ter certeza da configuração dos parâmetros de segurança e firewall.

3. Após a criação da instância, abra ela e vá em Secrets. Vamos criar 3 segredos diferentes:
   • Crie o segredo adb-tenantId utilizando o valor do Directory (tenant) Id.
   • Crie o segredo adb-appId utilizando o valor do Application (client) Id.
   • Crie o segredo adb-appKey utilizando o valor do SECRET DO APP.

4. Depois de criar os segredos, acesse o menu “Properties” e anote o DNS Name e o Resource ID.

Configurando o ADB com o Key-vault

1. Acesse seu workspace do ADB.
   

2. No ADB, acesse a home do workspace e edite a URL adicionando o sufixo #secrets/createScope , ficando com o seguinte endereço: https://<<URL do seu Workspace>>#secrets/createScope.

3. Na tela de Create Secret Scope entre com os valores e crie o escopo (lembre-se de anotar o Scope name que entrou):
   • Scope name: kvi-test (apenas um exemplo – este parâmetro será necessário para acionar os secrets do Key-vault);
   • Manage Principal: Creator – este parâmetro é configurável posteriormente pelo Databricks CLI ou Databricks APIs (veja neste link as boas práticas para criação de Secrets Scope).
   • DNS Name: insira o valor copiado do Key-vault.
   • Resource ID: insira o valor copiado do Key-vault.

Configurando a segurança do seu ADLS com o Service Principal do App

1. Caso não tenha um ADLS você pode criar uma instância nova do Storage Account, lembre de marcar a opção Hierarchical namespace nas opções avançadas.

2. Lembre-se também, caso não tenha, de criar um Container novo que pode ser feito dentro do Storage Account em Container.
   

3. Acesso o Storage Explorer com a sua conta e acesse seu ADLS e encontre seu container (como por exemplo o “cont6” abaixo).
   

4. Clique com o botão direito no container e vá em Manage Access.
   Nele clique em Add, e busque pelo nome do app que você criou, como por exemplo databricks-users-test (lembre-se de clicar no search).

5. Após selecionar o usuário e clicar em Add marque as opção na linha Access a coluna Execute
   • É necessário que o Service Principal tenha permissão de Execute no nível do Container.

Agora você poderá configurar o ACL, os acessos granulares para cada arquivo, do ADLS utilizando Manage Access. Para este passo-a-passo vamos usar dois arquivos de exemplo.

Lembre-se que as permissões de ACL não são herdadas no ADLS, assim, caso os arquivos já existam no seu ADLS, você precisará adicionar a permissão de Read para cada arquivo e/ou pasta no caminho dele.

Para o exemplo adicionaremos permissão de Read no arquivo “IRIS.csv” e nenhuma permissão no “Movie Tweets.csv”.

1. Acesse seu workspace e crie um novo notebook.
2. Caso não tenha um cluster configurado, você pode utilizar os parâmetros abaixo para criar um (lembre-se que a opção “Enable credential passthrough for user-level data access” deve estar desabilitada).

Acessando o ADLS pelo ADB com autenticação OAuth e segurança no Service Principal

1. Acesse seu workspace e crie um novo notebook.

2. Caso não tenha um cluster configurado, você pode utilizar os parâmetros especificados na imagem abaixo para criar um.
   Lembre-se: que a opção “Enable credential passthrough for user-level data access” deve estar desabilitada.
   

3. Crie uma célula no seu notebook e utilize o seguinte script para configurar o acesso ao ADLS. Lembre-se de substituir os parâmetros para os que você configurou

dlname = '<<Storage Account>>' ##nome do seu Storage Account
#Variáveis que puxam os segredos do Key-vault (parâmetros necessários para acessar o ADLS)
appid = dbutils.secrets.get(scope = "<<secret scope do kvi>>", key = "adb-appId") #Identificação do App = adb-appId
appsecret = dbutils.secrets.get(scope = "<<secret scope do kvi>>", key = "adb-appKey") #Identificação da chave de segreto do App = adb-appKey
tenantid = dbutils.secrets.get(scope = "<<secret scope do kvi>>", key = "adb-tenantId") #Identificação do seu tenant = adb-tenantId

spark.conf.set("fs.azure.account.auth.type." + dlname + ".dfs.core.windows.net", "OAuth") 
spark.conf.set("fs.azure.account.oauth.provider.type." + dlname + ".dfs.core.windows.net", "org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider")
spark.conf.set("fs.azure.account.oauth2.client.id." + dlname + ".dfs.core.windows.net", appid) 
spark.conf.set("fs.azure.account.oauth2.client.secret." + dlname + ".dfs.core.windows.net", appsecret)
spark.conf.set("fs.azure.account.oauth2.client.endpoint." + dlname + ".dfs.core.windows.net", "https://login.microsoftonline.com/"+ tenantid +"/oauth2/token")

4. Agora você já pode testar o acesso ao ADLS.
   Veja no exemplo abaixo que conseguimos acessar o arquivo IRIS.csv, mas não conseguimos acessar o Movie Tweets.csv.
   

Atualmente, Data lake é uma peça essencial em todas as empresas e ferramentas como o ADLS e o ADB são revolucionárias e podem facilitar muito uma nova implementação.

Por isso, utilizá-los em ambientes cloud como o Azure parece ser o caminho mais prático, contudo, existem aspectos que precisam ser analisados antes de adotá-los para que você consiga extrair o máximo de valor que eles podem trazer para sua empresa de forma escalável e sustentável.