Gerenciar identidades, permissões e privilégios para LakeFlow Jobs

Este artigo contém recomendações e instruções para gerenciar identidades, permissões e privilégios para LakeFlow Jobs.

nota

Os segredos não são removidos da transmissão de um cluster Spark driver log stdout e stderr. Para proteger dados confidenciais, os drivers default, Spark e logs podem ser visualizados apenas por usuários com permissão CAN MANAGE em Job, modo de acesso dedicado e clustering de modo de acesso padrão. Para permitir que os usuários com permissão CAN ATTACH TO ou CAN RESTART acessem view e logs nesses clusters, defina a seguinte propriedade de configuração Spark na configuração do clustering: spark.databricks.acl.needAdminPermissionToViewLogs false.

No modo de acesso compartilhado sem isolamento, o driver Spark logs pode ser visualizado por usuários com permissão CAN ATTACH TO, CAN RESTART ou CAN MANAGE. Para restringir o acesso ao arquivo logs apenas aos usuários com permissão CAN MANAGE, defina spark.databricks.acl.needAdminPermissionToViewLogs como true.

Consulte Spark configuration para saber como adicionar propriedades de Spark a uma configuração de clustering.

PrivilégiosJob e o usuário de execução

Os trabalhos são objetos no Databricks e têm privilégios que permitem que você acesse ou gerencie esses trabalhos. Esta página descreve esses privilégios como privilégios de trabalho (ou permissões).

Os trabalhos também executam e realizam tarefas em nome de um usuário (ou principal) que tem seus próprios privilégios para agir sobre o recurso ao qual o trabalho faz referência. O usuário que o Job representa é chamado de usuário de execução , e esses privilégios são chamados nesta página de privilégios de execução (ou permissões). Os privilégios de execução como usuário são usados quando o Job é executado.

Por exemplo, se o usuário A cria um Job e define a execução como usuário para o usuário B , o Job será executado com os privilégios do usuário B. Se o usuário C executar o Job, o Job ainda será executado com os privilégios do usuário B. Isso significa que é possível dar a alguém a capacidade de executar um Job para obter informações de um conjunto de dados ao qual ele próprio não tem acesso.

privilégios padrão para o Job

Os trabalhos têm os seguintes privilégios definidos por default:

• O criador do trabalho recebe a permissão IS OWNER no trabalho.
• Os administradores do espaço de trabalho recebem a permissão CAN MANAGE no trabalho.
• O criador do trabalho é definido para execução como .
• As permissões de execução do usuário são usadas ao executar o Job (incluindo a tarefa dentro do Job).

Como o default é definir o criador como proprietário e a execução como usuário, os privilégios do criador são usados ao executar o Job por default. Databricks recomenda alterar a execução como usuário para uma entidade de serviço, para que os privilégios possam ser controlados separadamente dos privilégios do proprietário e para que o trabalho não seja interrompido quando o proprietário sair ou alterar os privilégios.

Permissões de administrador para o trabalho

Pelo site default, os administradores do workspace podem alterar o proprietário do trabalho ou a execução como configuração para qualquer usuário ou entidade de serviço no workspace. Os administradores de conta podem configurar a opção RestrictWorkspaceAdmins para alterar esse comportamento. Consulte Restringir administradores do workspace.

Como o Job interage com as permissões do site Unity Catalog?

Execução de tarefas como a identidade do usuário na configuração execução como . Ao executar tarefa, essa identidade é avaliada em relação às concessões de permissão para o seguinte recurso que pode ser usado nessas tarefas:

• Unity Catalog-gerenciar ativo, incluindo tabelas, volumes, modelos e visualização.
• Listas de controle de acesso legado da tabela (ACLs) para ativos registrados no site legado Hive metastore.
• ACLs para compute, Notebook, consultas e outros workspace ativos.
• Segredos da Databricks. Veja Gerenciamento secreto.

nota

Unity Catalog As concessões e as ACLs de tabela herdadas exigem modos de acesso compute compatíveis. Consulte Configurar compute para o trabalho.

Quando os privilégios são avaliados?

Os privilégios Job são avaliados quando um usuário executa uma ação naquele trabalho, como editar ou executar o trabalho.

execução, pois os privilégios são avaliados durante a execução de um trabalho. Portanto, cada tarefa pode verificar privilégios quando a tarefa começar ou durante a execução.

nota

Nem todos os privilégios de execução são verificados no início da execução de um trabalho. Se você alterar os privilégios do usuário enquanto um trabalho estiver em execução, especialmente se você remover privilégios, o trabalho poderá falhar antes de ser concluído.

SQL tarefa e permissões

O arquivo tarefa é o único tipo de tarefa SQL que respeita totalmente a execução do usuário.

SQL consultas, alertas e tarefas do painel legado respeitam as configurações de compartilhamento definidas.

• Execução como proprietário : a execução da tarefa agendada SQL sempre usa a identidade do proprietário do ativo SQL configurado.
• execução como visualizador : a execução da tarefa agendada SQL sempre usa a identidade definida no campo Job execução as .

Para saber mais sobre as configurações de compartilhamento de consultas, consulte Configurar permissões de consulta.

Exemplo

O cenário a seguir ilustra a interação das configurações de SQL compartilhamento e a configuração Job execution as :

• O usuário A é o proprietário da consulta SQL denominada my_query.
• O usuário A configura o site my_query com a configuração de compartilhamento execução como proprietário .
• O usuário B programa my_query como uma tarefa em um trabalho chamado my_job.
• O usuário B configura my_job para executar com uma entidade de serviço chamada prod_sp.
• Quando o my_job executa, ele usa a identidade do Usuário A para executar o my_query.

Agora, suponha que o usuário B não queira esse comportamento. A partir da configuração existente, ocorre o seguinte:

• O usuário A altera a configuração de compartilhamento do site my_query para execução como visualizador .
• Quando my_job execução, ele usa a identificação prod_sp.

Configure a execução como usuário para execução do Job

Para alterar a configuração executar como , o senhor deve ter a permissão CAN MANAGE ou IS OWNER no Job.

O senhor pode definir a execução como configuração para si mesmo ou para qualquer entidade de serviço no site workspace no qual o senhor tem o direito de usuário da entidade de serviço .

Para definir a execução como configuração para um trabalho na interface do usuário workspace, selecione um trabalho existente usando as etapas a seguir:

1. Na barra lateral do site Databricks workspace, clique em Jobs & pipeline .
2. Opcionalmente, selecione os filtros Trabalhos e De minha propriedade para facilitar a localização do trabalho.
3. Clique no nome do trabalho na lista.
4. No painel lateral Detalhes do job , clique no ícone de lápis ao lado do campo Executar como .
5. Pesquise e selecione um usuário ou entidade de serviço.
6. Clique em Salvar .

Para obter mais informações sobre como trabalhar com entidades de serviço, consulte o seguinte:

• Entidades de serviço
• Funções para gerenciar diretores de serviços
• Liste a entidade de serviço que o senhor pode usar.

Práticas recomendadas para governança de trabalho

Databricks recomenda o seguinte para todos os trabalhos de produção:

• execução production Job usando a entidade de serviço

  Execução de Jobs como criador do Job por default. Se o usuário executado sair da sua organização, o trabalho poderá falhar.

  Se você atribuir a execução como usuário a uma entidade de serviço, a execução do trabalho usará as permissões da entidade de serviço e não será alterada quando os usuários saírem ou alterarem os privilégios.

  Em default, os administradores de workspace podem gerenciar as permissões de trabalho e reatribuir a propriedade, se necessário.

  Usar a entidade de serviço para produção também permite restringir permissões de gravação em dados de produção. Se você executar um Job usando as permissões de um usuário, esse usuário precisará das mesmas permissões para editar os dados de produção exigidos pelo Job.

• Sempre use configurações compatíveis com o Unity Catalog compute

  Unity Catalog A governança de dados exige que o senhor use uma configuração compatível com compute.

  O senhor pode usar o serverless compute para o trabalho e o armazém SQL sempre usa o Unity Catalog.

  Para trabalhos com o clássico compute, Databricks recomenda o modo de acesso padrão para cargas de trabalho compatíveis. Use o modo de acesso dedicado quando necessário.

  LakeFlow O pipeline declarativo configurado com Unity Catalog tem algumas limitações. Consulte Limitações.

• Restringir privilégios de trabalho em trabalho de produção

  Os privilégios Job controlam quem pode view, executar ou gerenciar o trabalho.

  • Os usuários que view a configuração do trabalho ou monitoram a execução precisam da permissão Can view .
  • Os usuários que acionam, param ou reiniciam a execução do trabalho precisam da permissão Can gerenciar execução .
  • Somente conceda os privilégios Can gerenciar ou Is Owner a usuários que tenham confiança para modificar o código de produção.

Controle o acesso a um trabalho

Job O controle de acesso permite que os proprietários e administradores do trabalho concedam permissões refinadas ao trabalho. As seguintes permissões estão disponíveis:

nota

Cada permissão inclui as concessões de permissões abaixo dela na tabela a seguir.

Permissão	Conceder
É o proprietário	A identidade usada para execução é por default. Você pode definir a execução como usuário para substituir isso.
Can Manage (Pode gerenciar)	Pode editar a definição do trabalho, incluindo configuração, tarefa e permissões. Pode pausar e retomar um programar.
Pode gerenciar a execução	Pode acionar e cancelar a execução do trabalho.
Pode ver	Pode view os resultados da execução do trabalho, incluindo detalhes, história e status.

• O criador de um trabalho tem a permissão IS OWNER por default.

• Um job não pode ter mais de um proprietário.

• Não é possível atribuir a permissão IS OWNER a um grupo como proprietário.

• Os trabalhos acionados por meio do execução Now assumem as permissões do usuário do executa (o proprietário, por default) e não do usuário que emitiu o execução Now .

• O controle de acesso a trabalhos se aplica aos trabalhos exibidos na interface de usuário de trabalhos e pipeline e sua execução. Não se aplica a:

  • Notebook fluxo de trabalho que execução modular ou código vinculado. Eles usam as permissões do próprio Notebook. Se o Notebook vier de Git, uma nova cópia será criada e seus arquivos herdarão as permissões do usuário que acionou a execução.

  • Trabalhos enviados pela API. Eles usam as permissões default do Notebook, a menos que o senhor defina explicitamente access_control_list na solicitação API.

Para obter informações sobre os níveis de permissão de trabalho, consulte Job ACLs.

Configurar permissões de trabalho

Para configurar as permissões de um trabalho na interface de usuário workspace, selecione um trabalho existente usando as etapas a seguir:

1. Na barra lateral do site Databricks workspace, clique em Jobs & pipeline .
2. Opcionalmente, selecione os filtros Empregos e de minha propriedade .
3. Clique no link Nome do seu trabalho.
4. No painel de detalhes doJob , clique em Edit permissions (Editar permissões ). A caixa de diálogo Configurações de permissão é exibida.
5. Clique no campo Select User, Group or entidade de serviço e comece a digitar um usuário, grupo ou entidade de serviço. O campo pesquisa todas as identidades disponíveis no site workspace.
6. Clique em Adicionar .
7. Clique em Salvar .

Gerenciar o proprietário do trabalho

Somente os administradores do site workspace podem editar o proprietário do trabalho. Deve ser atribuído exatamente um proprietário do trabalho. Job Os proprietários podem ser usuários ou entidades de serviço.