Atribuir compute recurso a um grupo

Este artigo explica como criar um recurso compute atribuído a um grupo usando o modo de acesso Dedicado .

O modo de acesso de grupo dedicado permite que os usuários obtenham a eficiência operacional de um clustering de modo de acesso padrão e, ao mesmo tempo, ofereçam suporte seguro a linguagens e cargas de trabalho que não são compatíveis com o modo de acesso padrão, como Databricks Runtime para ML, Spark biblioteca do machine learning (MLlib), RDD APIs e R.

Requisitos

Para usar o modo de acesso de grupo dedicado:

• O site workspace deve estar habilitado para Unity Catalog.
• O senhor deve usar o site Databricks Runtime 15.4 ou o acima.
• O grupo atribuído deve ter permissões CAN MANAGE em uma pasta workspace, onde poderá manter o Notebook, os experimentos ML e outros artefatos workspace usados pelo agrupamento 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 compute pode ser atribuído a um único usuário ou grupo, permitindo que apenas o(s) usuário(s) atribuído(s) tenha(m) acesso para usar o recurso compute.

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

Criar um recurso compute dedicado a um grupo

1. Em seu site Databricks workspace, vá para compute e clique em Create compute .
2. Expanda a seção Avançado .
3. Em Access mode (Modo de acesso ), clique em Manual e selecione Dedicated (anteriormente: Single-user) no menu dropdown.
4. No campo Usuário ou grupo único , selecione o grupo que deseja atribuir a esse recurso.
5. Defina as outras configurações desejadas de compute e clique em Create .

Práticas recomendadas para gerenciar o clustering de grupos

Como as permissões de usuário têm escopo reduzido para o grupo ao usar o agrupamento de grupos, o site Databricks recomenda a criação de uma pasta /Workspace/Groups/<groupName> para cada grupo que o senhor planeja usar com um agrupamento de grupos. Em seguida, atribua as permissões CAN MANAGE na pasta ao grupo. Isso permite que os grupos evitem erros de permissão. Todo o Notebook do grupo e o workspace ativo devem ser gerenciados na pasta do grupo.

O senhor também deve modificar as seguintes cargas de trabalho para execução em clustering de grupo:

• MLflow: Certifique-se de que o senhor execute o Notebook a partir da pasta do grupo ou execute mlflow.set_tracking_uri("/Workspace/Groups/<groupName>").
• AutoML: Defina o parâmetro opcional experiment_dir como “/Workspace/Groups/<groupName>” para sua AutoML execução.
• dbutils.notebook.run: Certifique-se de que o grupo tenha permissão READ no Notebook que está sendo executado.

Comportamento de permissão no agrupamento de grupos

Todos os comandos, consultas e outras ações executadas em um agrupamento de grupos usam as permissões atribuídas ao grupo, não ao usuário individual.

As permissões de usuários individuais não podem ser aplicadas porque todos os membros do grupo têm acesso total ao Spark APIs e ao ambiente compartilhado compute. Se as permissões baseadas no usuário fossem aplicadas, um membro poderia consultar dados restritos e outro membro sem acesso ainda poderia recuperar os resultados por meio do ambiente compartilhado. Portanto, o grupo em si, e não o usuário que é membro do grupo, deve ter as permissões necessárias para realizar a ação com êxito.

Por exemplo, o grupo precisa de permissão explícita para consultar uma tabela, acessar um escopo secreto ou segredo, usar uma credencial de conexão Unity Catalog, acessar uma pasta Git ou criar um objeto workspace.

Exemplo de permissões de grupo

Quando o senhor cria um objeto de dados usando o agrupamento de grupos, o grupo é atribuído como proprietário do objeto.

Por exemplo, se o senhor tiver um Notebook anexado a um grupo de clustering e executar o seguinte comando:

SQL

use catalog main;
create schema group_cluster_group_schema;

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

SQL

describe schema group_cluster_group_schema;

Grupo de auditoria dedicado à atividade compute

Há duas key identidades envolvidas quando um grupo de clustering executa uma carga de trabalho:

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

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

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

O exemplo de consulta a seguir extrai os metadados de identidade de uma ação realizada com o agrupamento de grupos:

SQL

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 audit log para obter mais exemplos de consultas. Consulte a referência da tabela do sistema Audit log.

Problemas conhecidos

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

Limitações

O acesso dedicado a grupos tem as seguintes limitações:

• As tabelas do sistema de linhagem não registram as identidades identity_metadata.run_as (o grupo de autorização) ou identity_metadata.run_by (o usuário de autenticação) para cargas de trabalho em execução em um cluster de grupo.
• A auditoria logs entregue ao armazenamento do cliente não registra as identidades identity_metadata.run_as (o grupo de autorização) ou identity_metadata.run_by (o usuário de autenticação) para cargas de trabalho em execução em um cluster de grupo. O senhor deve usar a tabela system.access.audit para view os metadados de identidade.
• Quando anexado a um agrupamento de grupos, o Catalog Explorer não filtra por ativo somente acessível ao grupo.
• Os gerentes de grupo que não são membros do grupo não podem criar, editar ou excluir clustering de grupo. Somente os administradores do workspace e os membros do grupo podem fazer isso.
• Se um grupo for renomeado, o senhor deverá atualizar manualmente todas as políticas do site compute que fazem referência ao nome do grupo.
• O agrupamento de grupos não é compatível com o espaço de trabalho com ACLs desativadas (isWorkspaceAclsEnabled == false) devido à falta inerente de segurança e de controles de acesso a dados quando as ACLs do site workspace estão desativadas.
• O comando %run atualmente usa as permissões do usuário em vez das permissões do grupo quando executado em um agrupamento de grupos. Alternativas como dbutils.notebook.run() usam corretamente as permissões do grupo.
• A função is_member(<group>) retorna false quando invocada em um agrupamento de grupos porque o grupo não é membro de si mesmo. Para verificar corretamente a associação entre o agrupamento de grupos e outros modos de acesso, use is_member(<group>) OR current_user() == <group>.