Acesso dedicado ao grupo compute

O compute de grupo dedicado no Databricks executa notebooks e jobs usando as permissões de um grupo atribuído. Você pode compartilhar o recurso de compute com membros do grupo e usuários que têm permissão para assumir o grupo.

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 suporta com segurança linguagens e workloads que não são suportados pelo modo de acesso padrão, como Databricks Runtime para ML, APIs de Resilient Distributed Dataset (RDD) e R.

Os clusters de grupo são uma maneira de assumir uma função no Databricks. Quando um usuário se conecta a um cluster de grupo, as permissões de identidade do usuário são substituídas pelas permissões do grupo para operações nesse cluster. Isso é equivalente a assumir o grupo como uma função durante a duração da sessão do cluster. Para outros métodos de assumir uma função, incluindo o alternador de função, CLI e API, consulte Alternar funções RBAC.

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 deve ser um grupo de account atribuído ao Workspace.
• 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, anteriormente modo de acesso de usuário único, atribui um recurso de compute a um usuário ou a um grupo. Um recurso de compute atribuído a um grupo é chamado de cluster de grupo. Apenas o usuário atribuído, ou os usuários que podem agir como o grupo atribuído, podem execução workloads nele.

Criar um recurso compute dedicado a um grupo

Para criar um compute de grupo, você precisa de permissão para usar uma política de compute ou o direito de criação de cluster irrestrito. A menos que você seja um administrador de workspace, você também deve ser membro do grupo atribuído ou ter permissão para assumi-lo.

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 .

Conceder acesso ao compute do grupo

Para usar um cluster de grupo, você precisa das duas opções a seguir:

• A permissão CAN ATTACH TO no recurso de compute.
• Associação ao grupo atribuído, incluindo através de um grupo aninhado, ou permissão para assumir o grupo atribuído.

Atribuir um grupo a um recurso de compute concede automaticamente a esse grupo CAN ATTACH TO. Você pode conceder permissões de compute a usuários ou grupos adicionais, mas isso não altera o grupo atribuído ou a identidade da carga de trabalho. Esses usuários ainda precisam ser membros ou ter permissão para assumir o grupo atribuído. Ser um gerente de grupo sozinho não concede permissão para criar, editar, excluir ou usar o cluster.

Para conceder acesso ao compute, você deve ter CAN MANAGE no recurso de compute:

1. Na barra lateral, clique em Compute .
2. Na linha do recurso de compute, abra o menu kebab e selecione Editar permissões .
3. Em Configurações de permissões , clique no menu dropdown Selecionar usuário, grupo ou Service Principal... e selecione o usuário ou grupo.
4. Selecione a permissão CAN ATTACH TO no dropdown de permissões.
5. Clique em Adicionar e, depois, em Salvar .

Consulte Permissões de compute.

Para editar ou excluir permanentemente um cluster de grupo, você precisa de CAN MANAGE no recurso de compute. A edição também requer a participação ou a permissão para assumir o grupo atribuído, a menos que você seja um administrador de workspace.

Usar o compute do grupo de um notebook

Para execução de um notebook com as permissões do grupo atribuído:

1. Abra um notebook em uma pasta de workspace que o grupo atribuído possa acessar.

2. No seletor de compute do notebook, selecione o cluster do grupo. Se não estiver listado, clique em Mais… para encontrá-lo.

3. Em uma célula SQL, ou em uma célula que começa com %sql, execução o seguinte comando para verificar a identidade da sessão:

   SQL

   SELECT session_user();

O resultado é o nome do grupo atribuído. Conceda permissões de dados e workspace a esse grupo para as operações que o notebook executa. Suas permissões pessoais não são adicionadas às permissões do grupo no cluster.

Se você já está atuando como uma função através do seletor de função do workspace, essa função deve corresponder ao grupo atribuído ao cluster. Consulte Alternar funções RBAC.

Para obter mais informações sobre anexar notebooks, consulte Anexar um notebook a um recurso de compute de uso geral.

execução Job como um grupo

Os Job podem ter execução com as permissões de um grupo, inclusive quando você configura o Job através da API ou SDK. Nos detalhes do Job, configure execução como para o grupo atribuído ao recurso de compute. O grupo precisa de permissão para acessar os notebooks, arquivos e dados usados pelo job.

Em uma solicitação da Jobs API, defina run_as.group_name como o nome do grupo:

JSON

{
  "run_as": {
    "group_name": "analytics-team"
  }
}

Para os passos de configuração, requisitos de grupo e comportamento quando uma tarefa usa compute dedicado atribuído a uma identidade diferente, consulte Definir Execução como para um grupo.

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. A identidade que inicia a carga de trabalho no cluster de grupo
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: A identidade de autenticação que inicia a ação.
• identity_metadata.run_as: o grupo de autorização cujas permissões são usadas para a ação.

Para cargas de trabalho interativas, run_by identifica o usuário. Para cargas de trabalho de job, ele identifica o service principal de aplicativo do serviço de Jobs. Consulte Definir execução como para um grupo.

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.

Os logs de auditoria entregues ao armazenamento do cliente também oferecem suporte a metadados de identidade. O JSON entregue usa identityMetadata.runAs para o grupo de autorização e identityMetadata.runBy para a identidade de autenticação. Esses campos não são preenchidos para cada evento de auditoria. Consulte Referência de registro de auditoria.

Limitações conhecidas

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

• Jobs que usam Git falham porque o diretório temporário que o job usa para verificar o repo Git não é gravável. Use pastas Git em vez disso.
• O campo created_by nas tabelas do sistema de linhagem de tabela e coluna registra o grupo. Essas tabelas não registram separadamente o usuário que iniciou a workload.
• Quando anexado a um clustering de grupo, o Catalog Explorer não filtra por ativo somente acessível ao grupo.
• 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.
• Os clusters de grupo não são suportados em Workspace onde as listas de controle de acesso (ACLs) estão desabilitadas (isWorkspaceAclsEnabled é false), porque esses Workspace não possuem controles de segurança e acesso a dados.
• O comando %run e outras ações no contexto do notebook usam as permissões do usuário em vez das permissões do grupo. Isso ocorre porque essas ações são gerenciadas pelo ambiente do notebook, não pelo ambiente do cluster. Comandos alternativos como dbutils.notebook.run() são objeto de execução no cluster e, portanto, usam as permissões do grupo.
• A função is_member(<group>) retorna false quando invocada em um cluster de grupo porque o grupo não é um membro de si mesmo. Para verificar a participação em clusters de grupos e outros modos de acesso, use is_member(<group>) OR session_user() = <group>.
• A AI Search tem restrições quando você atua como um grupo. Consulte operações suportadas e restrições de índice.
• A exclusão de arquivos e pastas não é compatível com o agrupamento de grupos.
• O arquivo upload UI não é compatível com o agrupamento de grupos.