Como o Databricks impõe o isolamento do usuário?

Esta página explica como o Azure Databricks usa o Lakeguard para impor o isolamento do usuário em ambientes de computação compartilhada e controle de acesso refinado na computação dedicada.

O que é Lakeguard?

O Lakeguard é um conjunto de tecnologias no Databricks que impõem isolamento de código e filtragem de dados para que vários usuários possam compartilhar o mesmo recurso de computação de forma segura e econômica e acessar dados com controles de acesso refinados em vigor na computação oferecendo acesso privilegiado ao computador.

Como funciona o Lakeguard?

Em ambientes de computação compartilhados, como computação clássica padrão, computação sem servidor e sql warehouses, o Lakeguard isola o código do usuário do mecanismo Spark e de outros usuários. Esse design permite que muitos usuários compartilhem os mesmos recursos de computação, mantendo limites rígidos entre usuários, o driver Spark e executores. Como esse isolamento está em vigor, a computação padrão pode impor nativamente controles de acesso refinados, como filtros de linha e máscaras de coluna.

O compute dedicado usa a arquitetura clássica do Spark, na qual o código do usuário não é isolado do motor, portanto não pode impor controles de acesso granulares já existentes sem correr o risco de coleta excessiva de dados. Em vez disso, o processamento dedicado delega a filtragem de dados ao processamento sem servidor do seu espaço de trabalho, que é isolado pelo Lakeguard e realiza essa filtragem em seu nome. É por isso que o controle de acesso refinado na computação dedicada requer que seu workspace seja habilitado para computação sem servidor. Consulte o controle de acesso refinado na computação dedicada.

Arquitetura clássica do Spark

A imagem a seguir mostra como, na arquitetura tradicional do Spark, os aplicativos de usuário compartilham uma JVM com acesso privilegiado ao computador subjacente.

Arquitetura tradicional do Spark

Arquitetura do Lakeguard

O Lakeguard isola todo o código do usuário usando contêineres seguros. Isso permite que várias cargas de trabalho executem no mesmo recurso de computação, mantendo o isolamento estrito entre os usuários.

Arquitetura do Lakeguard

Isolamento do cliente Spark

O Lakeguard isola os aplicativos cliente do driver Spark e uns dos outros usando dois componentes principais:

  • Spark Connect: O Lakeguard usa o Spark Connect (introduzido com o Apache Spark 3.4) para desacoplar aplicativos cliente do driver. Os aplicativos cliente e os drivers não compartilham mais a mesma JVM ou classpath. Essa separação impede o acesso a dados não autorizados. Esse design também impede que os usuários acessem dados resultantes da busca excessiva quando as consultas incluem filtros de nível de linha ou coluna.

    Observação

    O Spark Connect adia a análise e a resolução de nomes para o tempo de execução, o que pode alterar o comportamento do código. Consulte Comparar o Spark Connect com o Spark Classic.

  • Isolamento em contêiner: cada aplicativo cliente é executado em seu próprio ambiente de contêiner isolado. Isso impede que o código do usuário acesse os dados de outros usuários ou o computador subjacente. O sandboxing usa técnicas de isolamento baseadas em contêiner para criar limites seguros entre os usuários.

Isolamento de UDF

Por padrão, os executores do Spark não isolam UDFs. Essa falta de isolamento pode permitir que UDFs escrevam arquivos ou acessem o computador subjacente.

O Lakeguard isola o código definido pelo usuário, incluindo UDFs, em executores do Spark por:

  • Isolamento em sandbox do ambiente de execução nos executores do Spark.
  • Isolando o tráfego de saída da rede de UDFs para evitar acesso externo não autorizado.
  • Replicando o ambiente do cliente na área restrita da UDF para que os usuários possam acessar as bibliotecas necessárias.

Esse isolamento se aplica a UDFs em computação padrão e a UDFs em Python em computação sem servidor e warehouses SQL.