Partilhar via


Atribuir recursos de computação a um grupo

Importante

Este recurso está noPublic Preview .

Este artigo explica como criar um recurso de computação atribuído a um grupo através do modo de acesso dedicado.

O modo de acesso de grupo dedicado permite que os usuários obtenham a eficiência operacional de um cluster de modo de acesso padrão, ao mesmo tempo em que suportam com segurança linguagens e cargas de trabalho que não são suportadas pelo modo de acesso padrão, como Databricks Runtime for ML, Spark Machine Learning Library (MLlib), RDD APIs e R.

Ao habilitar a visualização pública do cluster de grupo dedicado, seu espaço de trabalho também terá acesso à nova interface do usuário de computação simplificada. Essa nova interface do usuário atualiza os nomes dos modos de acesso e simplifica as configurações de computação. Consulte Use o formulário simples para gerirde computação.

Requerimentos

Para usar o modo de acesso de grupo dedicado:

  • Um administrador de espaço de trabalho deve habilitar a pré-visualização de Compute: Clusters de grupo dedicados usando a interface do usuário de pré-visualizações. Consulte Gerir Pré-visualizações do Azure Databricks.
  • O espaço de trabalho deve estar habilitado para o Catálogo Unity.
  • Você deve usar o Databricks Runtime 15.4 ou superior.
  • O grupo atribuído deve ter permissões de CAN MANAGE numa pasta no espaço de trabalho onde pode manter cadernos, experimentos de ML e outros artefatos de trabalho usados pelo cluster do grupo.

O que é o modo de acesso dedicado?

O modo de acesso dedicado é a versão mais recente do modo de acesso de usuário único. Com acesso dedicado, um recurso de computação pode ser atribuído a um único usuário ou grupo, permitindo apenas que o(s) usuário(s) atribuído(s) acesse(m) o recurso de computação.

Quando um usuário está conectado a um recurso de computação dedicado a um grupo (um cluster de grupo), as permissões do usuário reduzem automaticamente o escopo para as permissões do grupo, permitindo que o usuário compartilhe o recurso com segurança com os outros membros do grupo.

Criar um recurso de computação dedicado a um grupo

  1. No seu espaço de trabalho do Azure Databricks, vá para Computação e clique em Criar compute.
  2. Expanda a seção Avançado.
  3. Em modo de acesso, clique em Manual e, em seguida, selecione Dedicado (anteriormente: Utilizador único) no menu suspenso.
  4. No campo Usuário único ou grupo, selecione o grupo que deseja atribuir a este recurso.
  5. Configure as outras configurações de computação desejadas e clique em Criar.

Práticas recomendadas para gerenciar clusters de grupo

Como as permissões de usuário têm como escopo o grupo ao usar clusters de grupo, o Databricks recomenda a criação de uma pasta /Workspace/Groups/<groupName> para cada grupo que você planeja usar com um cluster de grupo. Em seguida, atribua permissões CAN MANAGE à pasta para o grupo. Isso permite que os grupos evitem erros de permissão. Todos os blocos de anotações e ativos de espaço de trabalho do grupo devem ser gerenciados na pasta do grupo.

Você também deve modificar as seguintes cargas de trabalho para serem executadas em clusters de grupo:

  • MLflow: Certifique-se de executar o notebook a partir da pasta do grupo ou executar mlflow.set_tracking_uri("/Workspace/Groups/<groupName>").
  • AutoML: defina o parâmetro opcional experiment_dir como “/Workspace/Groups/<groupName>” para os seus processos AutoML.
  • dbutils.notebook.run: Verifique se o grupo tem permissão READ no bloco de anotações em execução.

Exemplo de permissões de grupo

Quando você cria um objeto de dados usando o cluster de grupo, o grupo é atribuído como proprietário do objeto.

Por exemplo, se tiveres um computador portátil anexado a um grupo de cluster e executares o seguinte comando:

use catalog main;
create schema group_cluster_group_schema;

Em seguida, execute esta consulta para verificar o proprietário do esquema:

describe schema group_cluster_group_schema;

Exemplo de descrição do esquema de grupo

Grupo de auditoria dedicado à atividade computacional

Há duas identidades principais envolvidas quando um cluster de grupo executa uma carga de trabalho:

  1. O usuário que está executando a carga de trabalho no cluster de grupo
  2. O grupo cujas permissões são usadas para executar as ações reais da carga de trabalho

A tabela do sistema de log de auditoria registra essas identidades sob os seguintes parâmetros:

  • identity_metadata.run_by: O usuário de autenticação que executa a ação
  • identity_metadata.run_as: O grupo de autorização cujas permissões são usadas para a ação.

A consulta de exemplo a seguir extrai os metadados de identidade para uma ação executada com o cluster de grupo:

select action_name, event_time, user_identity.email, identity_metadata
from system.access.audit
where user_identity.email = "uc-group-cluster-group" AND service_name = "unityCatalog"
order by event_time desc limit 100;

Consulte a referência da tabela do sistema de log de auditoria para obter exemplos de consultas. Consulte Referência da tabela do sistema de log de auditoria.

Problemas conhecidos

  • Os arquivos e pastas do espaço de trabalho criados a partir de clusters de grupo fazem com que o proprietário do objeto atribuído seja Unknown. Isso faz com que as operações subsequentes nesses objetos, como read, writee delete, falhem com erros de permissão negada.

Limitações

O modo de acesso de grupo dedicado Public Preview tem as seguintes limitações conhecidas:

  • As tabelas do sistema de linhagem não registram as identidades identity_metadata.run_as (o grupo autorizador) ou identity_metadata.run_by (o usuário de autenticação) para cargas de trabalho em execução em um cluster de grupo.
  • Os logs de auditoria entregues ao armazenamento do cliente não registram as identidades identity_metadata.run_as (o grupo autorizador) ou identity_metadata.run_by (o usuário de autenticação) para cargas de trabalho em execução em um cluster de grupo. Você deve usar a tabela system.access.audit para exibir os metadados de identidade.
  • Quando anexado a um cluster de grupo, o Catalog Explorer não filtra por ativos acessíveis apenas ao grupo.
  • Os gerentes de grupo que não são membros do grupo não podem criar, editar ou excluir clusters de grupo. Apenas os administradores do espaço de trabalho e os membros do grupo podem fazê-lo.
  • Se um grupo for renomeado, você deverá atualizar manualmente todas as políticas de computação que fazem referência ao nome do grupo.
  • Não há suporte para clusters de grupo para espaços de trabalho com ACLs desabilitadas (isWorkspaceAclsEnabled == false) devido à falta inerente de segurança e controles de acesso a dados quando as ACLs de espaço de trabalho estão desabilitadas.
  • Atualmente, o comando %run usa as permissões do usuário em vez das permissões do grupo quando executado em um cluster de grupo. Alternativas como dbutils.notebook.run() usam corretamente as permissões do grupo.