Configurar o Azure Private Link para Databricks

Ver no idioma original →

Autoria: Databricks · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Configure Azure Private Link for Databricks · Canal: Databricks · 21:22 · Assistir no YouTube

Tópicos: Cibersegurança e segurança de software, Dados, bancos de dados e embeddings, Infraestrutura e hardware de IA, Privacidade e proteção de dados

Resumo

O vídeo explica como o Azure Private Link protege conexões de entrada entre usuários e workspaces do Azure Databricks e conexões clássicas entre o compute e o plano de controle. A demonstração configura endpoints privados de Databricks UI API e de autenticação do navegador, além de zonas DNS privadas em uma rede virtual do workspace e em uma rede virtual de trânsito. Em seguida, Filipe testa a resolução DNS e o acesso a partir de uma máquina local e de uma VM na rede privada, e desativa o acesso público ao workspace. No fim, são apresentadas considerações sobre DNS, arquiteturas hub-and-spoke, conectividade com recursos adicionais e workspaces serverless.

Pontos-chave

• O Azure Private Link permite manter o tráfego entre usuários, workspaces e recursos do Azure fora de endpoints públicos.
• O private link clássico protege a conexão do compute clássico com o plano de controle por meio de um endpoint com sub-recurso Databricks UI API.
• O private link de entrada usa um endpoint Databricks UI API e outro de browser authentication para solicitações de autenticação e SSO.
• A demonstração cria o endpoint clássico na VNet do workspace e os endpoints de entrada e de autenticação do navegador na VNet de trânsito.
• A integração com uma zona DNS privada permite que os nomes do workspace sejam resolvidos para os endereços IP privados dos endpoints.
• A validação compara a resolução DNS e o acesso ao workspace a partir de uma máquina local e de uma VM na rede de trânsito.
• Para restringir o acesso ao privado, é necessário desativar o acesso público; clusters em execução podem impedir essa alteração.
• O endpoint privado de autenticação do navegador é regional, e é necessário configurar um por região com workspaces do Azure Databricks.
• Em arquiteturas hub-and-spoke, um endpoint e uma zona DNS privada podem ser compartilhados entre redes virtuais emparelhadas.
• Para acesso a contas de armazenamento e ao Event Hubs, o vídeo recomenda service endpoints; firewalls ou appliances virtuais podem ajudar na proteção contra exfiltração.

Capítulos

Início	Capítulo	Resumo
00:00	Visão geral do Azure Private Link	Filipe apresenta os benefícios da conectividade privada e diferencia os tipos de private link para Azure Databricks.
04:07	Preparação e configuração do endpoint clássico	São apresentados os pré-requisitos e a criação de um endpoint Databricks UI API na VNet do workspace para o private link clássico.
09:21	Endpoints de entrada e autenticação do navegador	A demonstração cria endpoints na VNet de trânsito, incluindo o endpoint de entrada e o recurso necessário para autenticação do navegador.
14:34	Validação de DNS e conectividade privada	O apresentador verifica os registros DNS e compara a resolução de nomes e a conexão a partir da máquina local e da VM de trânsito.
16:39	Desativação do acesso público	Após encerrar os clusters, o acesso público é desativado e os testes confirmam que o workspace só pode ser acessado pela rede privada.
18:44	Considerações de arquitetura e conectividade	O vídeo aborda endpoints regionais, DNS em redes hub-and-spoke, acesso a recursos adicionais e opções de proteção contra exfiltração.

Citações

Com o Private Link, você elimina a dependência desses endpoints públicos e habilita uma rede privada de ponta a ponta. — 01:01

O resultado desse comando NS lookup é um endereço IP privado. — 08:48

Isso funciona para minha VM jump box, mas não para meu desktop local. — 18:14

O uso de um NAT gateway para acesso público de saída geralmente não é uma prática recomendada. — 20:49

Conceitos e entidades

• Azure Private Link (conceito): Serviço do Azure que permite estabelecer conexões privadas com serviços e recursos sem depender de endpoints públicos.
• Azure Databricks (empresa): Plataforma abordada no vídeo, cuja conectividade privada é configurada para workspaces e recursos de compute.
• Databricks UI API (conceito): Sub-recurso usado pelos endpoints privados para tráfego de API REST e conectividade do compute clássico com o plano de controle.
• browser authentication (conceito): Sub-recurso de endpoint privado usado para proteger solicitações de autenticação do navegador e de SSO.
• private endpoint (conceito): Endpoint que conecta uma rede virtual a um serviço por meio de um endereço IP privado.
• private DNS zone (conceito): Zona DNS usada para resolver nomes de serviços para os endereços IP privados dos endpoints.
• VNet injection (conceito): Configuração em que o compute clássico do workspace é implantado em uma rede virtual gerenciada pelo cliente.
• Databricks CLI (ferramenta): Interface de linha de comando usada na demonstração para testar a conexão com o workspace.
• Filipe (pessoa): Sales solutions engineer da Databricks que apresenta e demonstra a configuração.

Tradução completa (pt-BR)

00:00 Olá, pessoal. Meu nome é Filipe. Sou engenheiro de soluções de vendas aqui na Databricks e hoje quero mostrar a vocês como configurar seus workspaces do Azure Databricks com suporte a private link. Antes de tudo, por que configuramos private links para workspaces do Azure Databricks? O Azure private link cria uma conexão privada e segura entre usuários, cargas de trabalho do Azure Databricks e seus serviços do Azure. Isso garante que o tráfego da rede seja totalmente privado e elimina a dependência de

00:30 endpoints públicos. Vamos dar uma olhada neste diagrama de arquitetura de alto nível. Como vocês podem ver, temos o plano de controle do Azure Databricks e a computação serverless. Também temos o plano de computação clássico hospedado na rede virtual que você gerencia, assim como seus próprios recursos, como contas de armazenamento, bancos de dados ou até recursos locais. Também temos usuários e aplicações que precisam acessar os workspaces do Azure Databricks, o Unity Catalog, os recursos de computação e assim por diante. Por padrão, toda essa comunicação

01:01 entre os recursos acontece por meio de endpoints públicos. Com o private link, você basicamente elimina a dependência desses endpoints públicos e habilita uma rede privada de ponta a ponta, garantindo que o tráfego permaneça isolado da internet pública. Isso ajuda as organizações a atender aos requisitos de segurança e conformidade, ao mesmo tempo que minimiza o risco de exfiltração de dados e reduz a superfície de ataque para cargas de trabalho sensíveis. O Azure Databricks oferece suporte a três tipos de private link. Primeiro, temos o private link de entrada, ou front-end,

01:33 que permite proteger a conexão dos usuários aos workspaces. Também temos o private link de saída, ou serverless, que protege as conexões entre a computação serverless e seus recursos do Azure. E temos o private link clássico, ou back-end, que permite uma conexão segura dos recursos de computação clássicos ao plano de controle do Azure Databricks. Neste vídeo, vamos nos concentrar no private link de entrada e no clássico, e discutiremos o private link de saída em um vídeo separado.

02:03 Começando pelo private link clássico, seu objetivo é proteger as conexões da computação clássica ao plano de controle. Para configurá-lo, você precisa configurar na sua conta um private endpoint vinculado ao seu workspace do Databricks, com o tipo de sub-recurso Databricks UI API. Depois que isso estiver configurado, seus recursos de computação se conectarão ao plano de controle usando o endereço IP desse private endpoint, e esse tráfego será roteado pelo Azure private link sem exposição à internet pública. O private link de entrada, por outro lado,

02:34 protege as conexões dos usuários aos workspaces do Databricks. Para essa configuração, temos dois endpoints diferentes. Um é um endpoint Databricks UI API, o mesmo sub-recurso que configuramos para o private link clássico, e também precisamos criar outro private endpoint com o tipo de sub-recurso browser authentication para conectar o private link ao Azure Intune ID para solicitações de autenticação e single sign-on. Também temos o novo private endpoint de acesso geral, usado para proteger o tráfego destinado aos recursos no nível da conta,

03:05 como o console da conta e o Genie One. Esses endpoints precisam estar acessíveis aos usuários finais. Normalmente, isso é feito criando-os em algum tipo de rede virtual de trânsito e, em seguida, configurando o acesso dos usuários à nuvem por meio de uma conexão VPN ou do ExpressRoute. Depois que a conectividade estiver estabelecida e os usuários puderem resolver consultas DNS por meio desses endereços IP de private endpoint, eles poderão acessar o workspace de forma privada. Antes de começarmos a configuração, gostaria de destacar os tipos de sub-recurso dos private endpoints

03:37 oferecidos pelo Azure Databricks. Os principais são o endpoint do workspace com o sub-recurso Databricks UI API, que lida com chamadas REST API para o private link de entrada e o clássico, e o endpoint de autenticação web com o tipo de sub-recurso browser authentication, usado para solicitações de single sign-on. Também temos o endpoint de acesso geral, que protege o tráfego destinado aos recursos no nível da conta, e o private endpoint service direct, para serviços que exigem alto desempenho, como zero bus e lake base.

04:07 Esses dois endpoints também serão abordados em vídeos separados. Certo, agora faremos uma demonstração rápida da configuração do private link. Antes disso, alguns pré-requisitos. Se quiser fazer a configuração por conta própria, você precisa ter permissões do Azure para gerenciar redes virtuais, criar private endpoints e gerenciar registros DNS. Vamos começar a demonstração com um workspace com injeção em VNet, que precisa estar no plano Premium. Para o private link de entrada, vou usar uma rede virtual de trânsito com uma máquina virtual jump box,

04:38 mas, em cenários reais de produção, você deve ter uma solução que forneça conectividade para recursos locais, como um gateway VPN ou o ExpressRoute. Por fim, é uma prática recomendada hospedar o private endpoint de browser authentication em um workspace dedicado para evitar um ponto único de falha. Esta é a arquitetura que propomos. Meu workspace tem injeção em VNet, e é nessa VNet do workspace que vocês veem à direita que serão criados os endpoints Databricks UI API para o private link clássico, ou back-end.

05:09 À esquerda, temos a rede virtual de trânsito, onde está implantada minha máquina virtual jump box, e criaremos o endpoint Databricks UI API para o acesso por private link de entrada, ou front-end, junto com o workspace de browser authentication e o private endpoint de browser authentication. Então, vou começar pelo grupo de recursos do meu workspace e navegar até o workspace com injeção em VNet. Aqui, se eu clicar em “Ver mais”,

05:40 posso ver qual é a rede virtual na qual este workspace tem injeção em VNet. Agora vou navegar até “Configurações”, à esquerda, e clicar em “Rede”. Em seguida, em “Conexões de private endpoint”. Vou clicar para adicionar um private endpoint. Depois, vou preencher alguns detalhes aqui. A primeira coisa que preciso é informar um nome. Neste caso, vou simplesmente copiá-lo daqui. Em seguida, clicarei em “Avançar” e irei para

06:11 a seção de recursos. Para o sub-recurso de destino, clicarei no menu suspenso e escolher “Databricks UI API”. Depois, clicarei em “Avançar” para configurar a rede virtual. Aqui, selecionarei a rede virtual do meu workspace. Como vocês podem ver, minha VNet do workspace está aqui. Vou me certificar de que ela esteja na sub-rede correta. Como podem ver, tenho duas sub-redes usadas para a injeção em VNet e configurei uma sub-rede adicional para os private endpoints.

06:42 Depois de selecionar essa opção, vou manter as demais opções nos valores padrão e clicar em “Avançar” para configurar o DNS. Vou escolher a integração com uma zona DNS privada. E vou criá-la no mesmo grupo de recursos em que meu workspace está hospedado. Como podem ver, este é o grupo de recursos do meu workspace. Depois, clicarei em “Avançar”. Vou simplesmente pular a seção de tags aqui e ir para “Revisar e criar”. Em seguida, clicarei aqui para criar o private endpoint.

07:13 Certo, a implantação está sendo inicializada e deve levar alguns minutos para ser concluída. Vamos aguardar e já voltamos. Certo, como podem ver, meu recurso foi criado. Consegui implantar este private endpoint e posso até clicar em “Ir para o recurso” para ver o private endpoint criado aqui. Em seguida, vou testar a implantação e confirmar se meu workspace está realmente configurado com acesso privado de back-end. Vou voltar ao grupo de recursos do meu workspace. Vou clicar no meu workspace com injeção em VNet

07:45 e iniciá-lo. Aqui, vocês podem ver que meu workspace está implantado. A primeira coisa que vou fazer é navegar até “Computação”. Agora, vou tentar criar um recurso de computação. A primeira coisa que você precisa fazer para garantir que o private endpoint clássico esteja funcionando corretamente é iniciar um recurso de computação. Vou simplesmente dar a ele um nome, como “cluster de teste”. Vou desativar algumas opções. Vou me certificar de que ele não seja muito grande. Depois, clicarei em

08:15 “Criar”. A criação de um recurso de computação leva cerca de 5 a 6 minutos. Vou aguardar até que seja concluída e já voltamos. Certo. Meu cluster finalmente foi criado e agora vou acessar um notebook que criei aqui. Vou executar um comando simples de NS lookup. Certo? Estou apenas tentando validar a resolução DNS do URL do workspace. Posso copiá-lo diretamente do navegador aqui.

08:48 Então, estou executando um comando de shell. É por isso que tenho este comando mágico para o Sage aqui. Em seguida, vou executar uma consulta NS. Vou garantir que ela esteja vinculada ao meu cluster de teste, que acabei de criar. Certo. Depois, vou executar este comando. Certo. Como vocês podem ver, o resultado deste comando de consulta NS é um endereço IP privado. Certo? Isso confirma que minha conexão do cluster clássico com o plano de controle do Databricks está sendo feita por meio do

09:21 Private Link e usando um endereço IP privado. Na verdade, se eu quiser conferir, este deve ser exatamente o mesmo endereço IP do endpoint privado que acabei de criar também no vídeo. Em seguida, vamos configurar o Private Link de entrada. Primeiro, vou acessar este grupo de recursos, onde tenho minha rede virtual de trânsito, como vocês podem ver aqui, além da minha máquina virtual jump box. Certo? A primeira coisa que quero fazer é configurar a API da interface do Databricks

09:53 para o acesso privado de frontend. Certo? Primeiro, vou voltar ao meu workspace injetado em VNet. Vou novamente até as conexões de endpoint privado de rede e criarei um endpoint privado. Aqui está o grupo de recursos. Neste caso, posso escolher implantar este endpoint no grupo de recursos de trânsito, então é isso que vou fazer.

10:26 Certo? Agora, preciso fornecer um nome para este endpoint privado. Neste caso, vou apenas copiá-lo aqui. Depois, clicarei em Avançar. Vou escolher o mesmo sub-recurso. Neste caso, é a API da interface do Databricks. Em seguida, vou para a seção de rede virtual. Aqui, em vez de selecionar a VNet do workspace, vou selecionar minha rede virtual de trânsito. Vou garantir que ela esteja conectada à sub-rede de endpoint privado que configurei também nesta rede virtual de trânsito

10:57 E clicarei em Avançar para a seção de DNS. Também manterei ativada a opção de integração com a zona DNS privada. Aqui, vou apenas confirmar que o grupo de recursos é o grupo de recursos de trânsito, e não o grupo de recursos do workspace que configurei anteriormente. Se estiver tudo correto, clicarei em Avançar, depois em Revisar e criar, e também criarei este recurso.

11:27 Certo, agora meu recurso acabou de ser criado. Posso clicar aqui e acessar o recurso. Vocês podem ver que meu endpoint privado de entrada está configurado. Esse é o primeiro passo. Em seguida, vamos criar os recursos necessários para a autenticação do navegador. Então, aqui no meu grupo de recursos de trânsito, vou criar um novo recurso. A primeira coisa que preciso fazer é criar um workspace do Azure Databricks para

11:58 hospedar o endpoint privado de autenticação web. Então, vou clicar aqui em Criar Azure Databricks. Vou implantá-lo no grupo de recursos de trânsito e darei um nome a este workspace. Vou copiá-lo aqui. Pronto. Este é o nome do meu workspace. Vou garantir que ele esteja na mesma região que os outros workspaces ou recursos. Quanto ao tipo de workspace, vou escolher

12:29 serverless por enquanto, porque não quero gerenciar nenhum tipo de recurso de infraestrutura para este workspace. Então, vou mantê-lo como um workspace serverless. Em seguida, na seção de rede, vou desativar o acesso à rede pública e não vou configurar o acesso privado para este workspace de propósito. Portanto, ele não ficará acessível para nenhum usuário. Depois disso, posso pular as seções restantes e criar este recurso. A implantação do meu workspace serverless

13:01 foi concluída com sucesso. Agora posso clicar em Ir para o recurso. Em seguida, vamos configurar o endpoint privado de autenticação do navegador. Neste workspace que acabei de configurar, vou acessar a seção de rede. Depois, vou até as conexões de endpoint privado e crio um novo endpoint privado. Certo. Primeiro, preciso fornecer um nome. Este é o nome do meu endpoint privado. Clicarei em Avançar

13:31 e em Ir para o recurso. Para o sub-recurso de destino, posso escolher a autenticação do navegador e clicar em Avançar para a rede virtual. Em seguida, vou garantir que minha rede virtual de trânsito esteja selecionada. Vou escolher minha VNet de trânsito aqui e também selecionarei minha sub-rede de endpoint privado. Agora posso clicar em Avançar para o DNS. Depois, vou manter a integração com minha zona DNS privada. Quanto ao grupo de recursos, garanta

14:03 que você selecione o mesmo grupo de recursos em que implantou o Private Link de frontend. Neste caso, estou escolhendo o grupo de recursos de trânsito, que é o mesmo grupo de recursos em que implantei o outro endpoint para acesso de frontend. Depois disso, posso clicar em Avançar, pular a seção de tags e criar este recurso. Certo. Isso vai levar alguns minutos, então vamos aguardar e já voltamos. A implantação foi concluída. Posso ir

14:34 até o recurso. Aqui está meu endpoint privado. Agora vou voltar ao grupo de recursos de trânsito. Quero que vocês observem a zona DNS privada que foi criada. Como podem ver, se eu entrar aqui e acessar Gerenciamento de DNS e Conjuntos de registros, consigo ver os registros A registrados aqui. Tenho um registro A para o workspace. Como podem ver, esta é a URL do workspace: workspace.privatelink.azure-databricks.net. E então tenho dois registros que foram

15:05 criados automaticamente para o endpoint privado de autenticação do navegador. Agora que ele foi criado e esta zona DNS privada está vinculada à minha rede virtual de trânsito, onde minha máquina virtual jump box está implantada, podemos começar a testar. Para isso, vou usar esta configuração: à esquerda, tenho meu terminal, que está na minha máquina local.

15:36 À direita, tenho uma janela do PowerShell da máquina virtual jump box implantada na minha rede virtual de trânsito. Certo. Primeiro, vou executar um comando de consulta NS nos dois locais. Vamos ver que minha máquina local resolve para um endereço IP público, como vocês podem ver, enquanto minha máquina virtual resolve para um endereço IP privado, que é o endereço IP privado do

16:08 endpoint privado de frontend que configurei. Certo? Agora, se eu tentar me conectar ao workspace a partir dos dois locais, usando aqui um comando da Databricks CLI com um perfil que configurei previamente, posso executá-lo aqui e também na minha máquina virtual. Como vocês podem ver, consigo me conectar ao workspace tanto pela internet pública quanto usando meu endpoint privado. Então, agora que posso ver que esta conexão está

16:39 funcionando para minha máquina virtual, posso acessar meu workspace. Neste caso, vou voltar ao meu workspace injetado em VNet aqui e desativar o acesso público. Posso acessar a seção de rede e, em vez de permitir o acesso à rede pública, vou desativar essa opção. Também vou escolher nenhuma regra do Azure Databricks para as regras do NSG e clicar em Salvar. Essa atualização vai levar alguns

17:11 minutos e, quando terminar, voltaremos. É claro que isso vai falhar porque eu tinha alguns clusters clássicos iniciados. Então, primeiro preciso desligar esses recursos de computação. Agora que encerrei todos os meus clusters de computação, posso desativar essas opções e clicar em Salvar. Isso vai levar alguns minutos. Deve ser concluído, então também vamos ter que aguardar.

17:42 Agora que isso foi concluído, podemos fazer alguns testes adicionais para garantir que somente o acesso privado consiga chegar ao workspace. Primeiro, se eu tentar abrir este workspace, veremos que não consigo acessá-lo, certo? Sim, como vocês podem ver, aparece esta mensagem: “Não tenho autorização para acessar o workspace.” Isso acontece porque minha máquina local está usando um endereço IP público. Então, se eu tentar executar o mesmo comando que usei para validar a conectividade, ele não deverá mais funcionar

18:14 do meu laptop local. Como você pode ver, estou recebendo a mesma mensagem de erro. Agora, se eu tentar executar o mesmo comando nesta minha máquina virtual Windows, isso mesmo, aí está. Você pode ver que isso funciona para minha máquina virtual jump box, mas não funciona para meu desktop local. O motivo é que, mais uma vez, minha máquina virtual está se conectando ao espaço de trabalho por meio de um

18:44 endereço IP privado. Então, isso prova que só consigo acessar esse espaço de trabalho se estiver conectado a partir desta rede privada. Certo, antes de encerrarmos, vamos analisar algumas considerações adicionais. Quanto às configurações de ponto de extremidade privado, o ponto de extremidade privado para autenticação do navegador é regional. Você precisa configurar um ponto de extremidade privado para autenticação do navegador em cada região em que implantar espaços de trabalho do Azure Databricks. Além disso, os links privados clássico e de entrada

19:16 usam o mesmo tipo de sub-recurso de ponto de extremidade privado para a conectividade com o plano de controle. Em cenários hub-and-spoke, você pode usar o mesmo ponto de extremidade para o link privado clássico e o de entrada. Assim, na arquitetura hub-and-spoke, você pode configurar algo como isto, em que a rede virtual do espaço de trabalho está emparelhada com esta rede virtual de trânsito ou hub, que consolida todos os pontos de extremidade privados. Com esta opção, você também pode centralizar a resolução de DNS usando uma única zona DNS privada e vinculando-a

19:46 às duas redes virtuais. Quanto à configuração de DNS, para o link privado de entrada e para redes virtuais configuradas com DNS personalizado, você precisa garantir que os nomes de host possam ser resolvidos para os endereços IP corretos dos pontos de extremidade privados. Normalmente, isso envolve configurar seus servidores DNS para encaminhar consultas de todos os domínios do Databricks para o DNS interno do Azure. Não se esqueça de encaminhar os domínios listados aqui para garantir a resolução correta de DNS para seu espaço de trabalho e para o aplicativo Web.

20:17 Agora, quanto à conectividade com recursos adicionais, os clusters de computação clássicos também precisam de conectividade com contas de armazenamento, principalmente blob e ADLS, e com um hub de eventos gerenciado pelo Databricks, que não pode ficar atrás de um ponto de extremidade privado. Para esses recursos, há algumas opções de conectividade. A abordagem recomendada é usar pontos de extremidade de serviço para acessar contas de armazenamento e o hub de eventos e, opcionalmente, políticas de ponto de extremidade de serviço para proteção contra exfiltração.

20:49 Para proteger contra a exfiltração de dados para domínios públicos, você pode usar um firewall ou um dispositivo virtual e adicionar os domínios necessários à lista de permissões do firewall. Por fim, você pode usar um gateway NAT para acesso público de saída, mas isso geralmente não é uma prática recomendada, pois não há inspeção de tráfego nem proteção contra exfiltração. E, por último, o link privado clássico não se aplica a espaços de trabalho sem servidor. Mas você ainda pode configurar links privados de entrada e de saída, conforme necessário.

21:22 Espero que este vídeo tenha sido útil. Obrigado pelo seu tempo. >> [música]

Transcrição original

[00:00] Hey everyone, my name is Filipe. I am a sales solutions engineer here at Databricks and today I want to walk you through how to set up your Azure Databricks workspaces with private link support. First of all, why do we configure private links for Azure Databricks workspaces? Azure private link creates a private secure connection between users, Azure Databricks workloads, and your Azure services. Ensuring your network traffic is fully private and removing the dependency on

[00:30] public endpoints. Let’s take a look at this high-level architecture diagram. As you can see, we have the Azure Databricks control plane and serverless compute. We also have the classic compute plane hosted in the virtual network that you manage, as well as your own resources such as storage accounts, databases, or even on-premises resources. And we also have users and applications that must access the Azure Databricks workspaces, Unity Catalog, compute resources, and so on. By default, all this communication

[01:01] between resources happens through public endpoints. With private link, you basically remove the dependency on these public endpoints and enable end-to-end private networking, ensuring that your traffic remains isolated from the public internet. This helps organizations address security and compliance requirements while minimizing the risk of data exfiltration and reducing the attack surface for sensitive workloads. There are three types of private links supported by Azure Databricks. First, we have inbound or front-end

[01:33] private link, which allows you to secure the connection from users to workspaces. We also have outbound or serverless private link, which secures the connections between serverless compute and your Azure resources. And we have classic or back-end private link, um which enables a secure connection from classic compute resources to the Azure Databricks control plane. In this video, we’re going to focus on inbound and classic private link, and we will discuss outbound private link in a separate video.

[02:03] Starting with classic private link, its purpose is to secure connections from classic compute to the control plane. To set it up, you must configure a private endpoint in your account linked to your Databricks workspace with a sub resource type of Databricks UI API. After this is configured, your compute resources will connect to the control plane using this private endpoint IP address, and this traffic will be routed through Azure private link with no exposure to the public internet. Inbound private link, on the other hand,

[02:34] secures connections from users to Databricks workspaces. For this setup, we actually have two different endpoints. One is a Databricks UI API endpoint, the same sub resource we configured for classic private link, and we must also create another private endpoint with a sub resource type of browser authentication to connect private link to Azure Intune ID for single sign-on and authentication requests. We also have the newer general access private endpoint, which is used for securing traffic to the account-level

[03:05] resources such as the account console and Genie One. Now, these endpoints must be accessible to end users. Usually, this is achieved by having them created in some sort of transit virtual network, and then you configure access for your users to the cloud with either a VPN connection or ExpressRoute. After the connectivity is in place and the users can resolve DNS queries through these private endpoint IP addresses, they will be able to access the workspace privately. Before we get into the setup, I’d like to highlight the private endpoint sub

[03:37] resource types that Azure Databricks provides. The main ones are the workspace endpoint with the Databricks UI API sub resource, which handles REST API calls for inbound and classic private link, and the web authentication endpoint with a sub resource type of browser authentication used for single sign-on requests. We also have the general access endpoint for securing traffic to account level resources and the service direct private endpoint for performance intensive services like zero bus and lake base.

[04:07] These two endpoints will also be covered in separate videos. All right, we’ll now go through a quick demo of the private link setup and before we do so a few prerequisites. If you want to do the setup yourself, you must have Azure permissions to manage virtual networks, create private endpoints and manage DNS records. And we’ll start the demo from a VNet injected workspace, which must be on the premium plan. For the inbound private link, I will use a transit virtual network with a jump

[04:38] box virtual machine, but in real production scenarios, you should have a solution that provides connectivity for on-premises resources such as a VPN gateway or express route. And finally, it is a best practice to host the browser authentication private endpoint in a dedicated workspace to avoid a single point of failure. So, this is our proposed architecture. My workspace is VNet injected and this workspace VNet you see on the right side where the Databricks UI API endpoints for classic or back end private link

[05:09] will be created. On the left side, we have the transit virtual network where my jump box virtual machine is deployed and we will create the Databricks UI API endpoint for inbound or front end private link access along with the browser authentication workspace and the browser authentication private endpoint. So, I’m starting from my workspace resource group and first I’ll navigate to my VNet injected workspace. And here, I can see if I click see more,

[05:40] I can see the what’s the virtual network where this workspace is VNet injected. Um now what I’m going to do is navigate to settings on the left and click networking. Uh, and then private endpoint connections. I will click to add a private endpoint. And then I will fill in some details over here. First thing I need is to provide a name. In this case, I’m just going to copy it from here. Um, and then I will click next and go to

[06:11] the resource section. Um, for the target subresource, I will click on the drop-down and choose Databricks UI API. And I will click next for virtual network. Here, I will select my workspace virtual network. So, you can see I have my workspace VNet over here. And I’ll make sure that this is in the correct subnet. So, as you can see, I have two subnets that are uh used for VNet injection, and I configured an additional subnet for the private

[06:42] endpoints. Uh, once this is selected, I’ll keep the other options as defaults and click next for DNS. I will choose to integrate with a private DNS zone. And I will create it in the same resource group where my workspace is hosted. As you can see, this is my workspace RG. And then I will click next. Uh, I’ll just skip the tag section over here, go to review and create. And then I will click here to create the private endpoint. Um,

[07:13] All right, so this is initializing the deployment, and it should take a few minutes before this is completed. So, let’s wait for it, and then we’ll be right back. All right, so as you can see, my resource is now created. So, I was able to deploy this private endpoint, and I can even click go to resource and see the private endpoint created over here. Um, so next thing I’ll do is just test the deployment and make sure my workspace is really configured with back-end privately. So, I’m navigating back to my workspace resource group. I’ll click on my VNet

[07:45] injected workspace and I will launch it. Here you can see my workspace is deployed. Um the first thing I will do is navigate to compute. And now I’ll try to create a compute resource. So, the first thing you need to do to ensure that uh private and the classic private endpoint is working nicely is to have a compute resource spin up. So, I’m just going to name this test cluster or something. Um I’ll untoggle a few things. Make sure this is not too large. And then I’ll hit

[08:15] create. So, creating a compute resource takes around 5 to 6 minutes. So, I’ll just wait for it to be completed and then we’ll be right back. All right. So, my cluster is finally created and now I’m just going to go to a notebook that I created over here. And I’m going to run a simple NS lookup command. Okay? So, I’m just trying to validate the DNS resolution for the workspace URL. So, I can just copy it from the browser over here.

[08:48] Um then I’m running a shell command. So, this is why I have this magic command for a sage over here. And then I’m going to run an NS lookup. Make sure that this is attached to my test cluster that I just created. All right. And then I’m going to run this command. All right. So, as you can see um the result of this uh NS lookup command is a private IP address. All right? Which confirms that my connection from the classic cluster to the Databricks control plane is being handled through

[09:21] private link and going through a private IP address. In fact, if I want to double-check, this should be exactly the same IP address as the private endpoint that I just created um in the video as well. So, next we’ll go for inbound private link. So, the first thing is I’m going to navigate to this resource group where I have my transit virtual network, as you can see over here, as well as my jump box virtual machine. Okay? So, the first thing I want to do is configure the Databricks UI API

[09:53] endpoint for front-end private access. Okay? So, first thing I’m going to do is navigate back to my VNet injected workspace. I’m going to go again to network private endpoint connections, and I will create a private endpoint. So, here I have the resource group. Um well, in this case, I can actually choose to deploy this endpoint in the transit resource group, so that’s what I’m going to do.

[10:26] Okay? Now, I need to provide a name for this private endpoint. In this case, I’m just going to copy it here. Then, I’ll click next. I will choose the same sub resource. In this case, it’s Databricks UI API, then I’ll go to the virtual network section. Here, instead of selecting the workspace VNet, I’m going to select my transit virtual network. Um make sure this is connected to my private endpoint subnet that I configured in this transit virtual

[10:57] network as well. And I will click next for the DNS section. I’ll keep the integrate with private DNS zone option enabled as well. And here, I’m just going to make sure that the resource group is in the is the transit resource group and not the workspace resource group that I configured previously. So, if this is all correct, I’ll just click next, then I’ll click review and create, and I’ll create this resource as well.

[11:27] All right, so now my resource is just created. I can click here and go to the resource. You can see my uh inbound private endpoint is configured. So, that’s the first step. Next, uh we’re going to go ahead and create the resources that are required for browser authentication. So, here in my transit resource group, I will go ahead and create a new resource. And the first thing I need to do is create an Azure Databricks workspace to

[11:58] host the web authentication private So, I’m just going to go here, click create Azure Databricks. Um I’ll deploy this in the transit resource group, and I’ll give this workspace a name. Let me just copy it here. There we go. This is my the name of my workspace. Uh I’ll make sure this is Make sure this is in the same region as your other workspaces or your other resources as well. Um for the workspace type, I will choose

[12:29] serverless for now um because I don’t want to manage any sort of infrastructure resources for this workspace, so I’ll just keep it as a serverless workspace. Then, in the networking section, I will actually disable public network access and not configure access uh private access for this workspace intentionally. So, it’s not actually accessible for any users. Um once this is done, I can actually skip the remaining sections. And I’ll just go ahead and create this resource. So, my serverless workspace deployment

[13:01] succeeded. I can now click go to resource. And now we’re going to configure the browser authentication private endpoint. So, within this workspace that I just configured, I will navigate to networking. Um then I’ll go to private endpoint connections and create a new private endpoint. Okay. First thing I need to do is provide a name. Um this is the name of my private endpoint. And I’ll click next

[13:31] and go to resource. For the target sub resource, I can choose browser authentication and then click next for virtual network. And then I’ll make sure to select my transit virtual network. So, I’m just going to choose my transit VNet over here and I’ll choose my private endpoint subnet as well. Um now I can click next for DNS. And then I’ll make sure to keep this integrated with my private DNS zone. Um and for the resource group, make sure

[14:03] that you select the same resource group where you deployed the front-end private link. So, in this case, I’m choosing the transit resource group, which is the same RG that I deployed the other endpoint for front-end access. Um once this is done, I can just click next, skip the tag section, and I’ll just go ahead and create this resource. All right. This is once again going to take a few minutes, so let’s wait for it and we’ll be right back. This deployment is completed. I can go

[14:34] to the resource. Here’s my private endpoint. And I’ll just go back to the transit resource group. And what I want you to take a look at is the private DNS zone that was created. As you can see, if I go in here, navigate to DNS management and record sets, I can see the A records that were registered in here. So, I have one A record for the workspace. As you can see, this is the workspace URL. So, workspace.privatelink.azure-databricks.net. And then I have two records that were

[15:05] automatically created for the browser authentication private endpoint. Now that this is created and this private DNS zone is linked to my transit virtual network where my jump box virtual machine is deployed, we can now start testing this. So, to test this, I’m actually going to do this approach over here where in the left side, I have my terminal, which is in my local machine over here.

[15:36] On the right side, I have a PowerShell window from that jumpbox virtual machine that’s deployed in my transit virtual network. All right. The first thing I’m going to do is run an NS lookup command in both places. And what we’re going to see here is that my local machine resolves to a public IP address, as you can see, while my virtual machine resolves to a private IP address, which is the private IP address of the

[16:08] front-end private endpoint that I configured. Okay? And now, if I try to connect to the workspace from both locations, and here I’m using a Databricks CLI command with a profile that I preconfigured, um I can just run this, and I’ll run this uh in my virtual machine as well. And as you can see, I can connect to the workspace both from the public internet as well as using my private endpoint. So, what I’m going to do next, now that I can see that this connection is

[16:39] working for um for my virtual machine, is I can navigate to my workspace. So, in this case, I’m going to go back to my uh VNet injected workspace over here, and I’m going to disable public access. So, I can go to the networking section, and here instead of allow in the allow public network access option, I’ll just disable this, and I’ll choose no Azure Databricks rules for the NSG rules, and hit save. So, this update is going to take a few

[17:11] minutes, um and once this is finished, we’ll be right back. Of course, this is going to fail because I had some classic clusters spin up. So, first I need to uh turn off those uh compute resources. Now that I’ve terminated all my uh compute clusters, I can actually disable these options and click save. Now, this is going to take a few minutes. Uh it should be completed, so we’re going to have to wait for this as well.

[17:42] So, now that this is completed, we can do some additional testing to make sure that only uh private access can uh go through the workspace. So, first thing, if I try to launch this workspace, we’ll see that I cannot really access it, right? Yeah, as you can see, it just gives me this message, “I’m not authorized to access through the workspace.” And of course, because my local machine is coming from a public IP address. So, if I were to try to run that same command that I did to validate connectivity, it should no longer work

[18:14] from my local laptop. As you can see, I’m having the same error message. Now, if I try to run the same command from my uh Windows virtual machine over here, yep, there you go. You can see how this works for my uh my jump box virtual machine, but it doesn’t work for my local uh for my local desktop. The reason is because once again, my virtual machine is connecting to the workspace through a

[18:44] private IP address. So, this proves that I can only access this workspace if I’m connected from um this private network over here. Okay, before we wrap up, let’s take a look at some additional considerations. Regarding private endpoint arrangements, the browser authentication private endpoint is regional. You must configure one browser authentication private endpoint for each region where you deploy Azure Databricks workspaces. Also, both classic and inbound private

[19:16] links use the same private endpoint sub resource type for control plane connectivity. In hub and spoke scenarios, you can use the same endpoint for classic and inbound private link. So, in the hub and spoke architecture, you can set up something like this where your workspace virtual network is peered to this transit or hub virtual network, which consolidates all private endpoints. With this uh with this option, you can also centralize DNS resolution by having a single private DNS zone and linking it

[19:46] to both virtual networks. Regarding DNS configuration, for inbound private link and for virtual networks configured with custom DNS, you must ensure hostnames can resolve to the correct private endpoint IP addresses. Usually, this involves configuring your DNS servers to forward queries for all Databricks domain to Azure’s internal DNS. Make sure that you forward the domains you see here listed to ensure proper DNS resolution to your workspace and for web

[20:17] application. Now, for connectivity to additional resources, classic compute clusters also require connectivity to storage accounts, mostly blob and ADLS, and an event hub managed by Databricks, which cannot be placed behind a private endpoint. For these resources, there are a few options for connectivity. The recommended approach is to use service endpoints for storage account and event hub access, and optionally, service endpoint policies for exfiltration protection.

[20:49] For data exfiltration protection to public domains, you can use a firewall or virtual appliance and allow list the required domains in your firewall. And lastly, you can use a NAT gateway for outbound public access, but this is usually not a best practice since there’s no traffic inspection or as exfiltration protection. And finally, for serverless workspaces, classic private link is not applicable. But you can still configure inbound and outbound private link as required.

[21:22] Hope you found this video helpful and thank you for your time. >> [music]