Pular para o conteúdo principal

Listas de controle de acesso

Esta página descreve detalhes sobre as permissões disponíveis para os diferentes objetos workspace .

Visão geral das listas de controle de acesso

No SAP Databricks, é possível usar listas de controle de acesso (ACLs) para configurar a permissão de acesso a objetos de nível workspace. Os administradores do espaço de trabalho têm a permissão CAN MANAGE em todos os objetos de seu workspace, o que lhes dá a capacidade de gerenciar permissões em todos os objetos de seu espaço de trabalho. Os usuários têm automaticamente a permissão CAN MANAGE para os objetos que criam.

Gerenciar listas de controle de acesso com pastas

O senhor pode gerenciar as permissões do objeto workspace adicionando objetos a pastas. Os objetos em uma pasta herdam todas as configurações de permissões dessa pasta. Por exemplo, um usuário que tenha a permissão CAN RUN em uma pasta tem a permissão CAN RUN no alerta dessa pasta.

Se o senhor conceder a um usuário acesso a um objeto dentro da pasta, ele poderá view o nome da pasta principal, mesmo que não tenha permissões na pasta principal. Por exemplo, um Notebook chamado test1.py está em uma pasta chamada Workflows. Se o senhor conceder a um usuário a permissão CAN VIEW em test1.py e nenhuma permissão em Workflows, o usuário poderá ver que a pasta pai se chama Workflows. O usuário não pode acessar view ou qualquer outro objeto na pasta Workflows, a menos que tenha recebido permissões para isso.

alerta ACLs

Função

No Permissions

Pode executar

Can Manage (Pode gerenciar)

Ver na lista de alerta

ver alerta e resultado

Acionar manualmente a execução do alerta

Inscrever-se para receber notificações

Editar alerta

Modificar permissões

Excluir alerta

ACLs de arquivos

Função

No Permissions

Pode ver

Pode executar

Pode editar

Can Manage (Pode gerenciar)

Ler arquivo

Comentário

Anexar e desanexar arquivo

executar arquivo interativamente

Editar arquivo

Modificar permissões

nota

A interface do usuário workspace se refere ao acesso somente viewcomo CAN VIEW, enquanto o Permissions API usa CAN READ para representar o mesmo nível de acesso.

ACLs de pastas

Função

No Permissions

Pode ver

Pode editar

Pode executar

Can Manage (Pode gerenciar)

Listar objetos na pasta

Exibir objetos na pasta

Clonar e exportar itens

objetos de execução na pasta

Crie, importe e exclua itens

Mover e renomear itens

Modificar permissões

ACLs de pastas do Git

Função

No Permissions

Pode ler

Pode executar

Pode editar

Can Manage (Pode gerenciar)

Listar ativo em uma pasta

visualizar o ativo em uma pasta

Clonar e exportar ativo

execução executável ativo na pasta

Editar e renomear ativos em uma pasta

Crie uma ramificação em uma pasta

Trocar ramificações em uma pasta

Puxe ou empurre uma ramificação para dentro de uma pasta

Criar, importar, excluir e mover o ativo

Modificar permissões

Job ACLs

Função

No Permissions

Pode ver

Pode gerenciar a execução

É o proprietário

Can Manage (Pode gerenciar)

Ver detalhes e configurações do trabalho

ver resultados

Executar agora

Cancelar execução

Editar configurações de trabalho

Excluir job

Modificar permissões

nota
  • 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 um grupo a permissão É proprietário como proprietário.
  • Os trabalhos acionados por meio da execução Now assumem as permissões do proprietário do trabalho e não do usuário que emitiu a execução Now .
  • O controle de acesso a trabalhos se aplica ao trabalho exibido na interface de usuário LakeFlow Jobs 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.

ACLs de experimentos do MLflow

MLflow As ACLs de experimentos são diferentes para os experimentos em Notebook e para os experimentos em workspace. Notebook Os experimentos não podem ser gerenciados independentemente do Notebook que os criou, portanto, as permissões são semelhantes às permissões do Notebook.

Notebook ACLs

Função

No Permissions

Pode ver

Pode executar

Pode editar

Can Manage (Pode gerenciar)

visualizar células

Comentário

execução usando %run ou Notebook fluxo de trabalho

Anexar e desanexar o Notebook

execução comando

Editar células

Modificar permissões

ACLs de consulta

Função

No Permissions

Pode ver

Pode executar

Pode editar

Can Manage (Pode gerenciar)

visualizar as próprias consultas

Veja na lista de consultas

visualizar o texto da consulta

visualizar o resultado da consulta

Atualizar o resultado da consulta (ou escolher parâmetros diferentes)

Incluir a consulta em um painel

Alterar SQL warehouse ou fonte de dados

Editar texto da consulta

Modificar permissões

Excluir consulta

ACLs secretas

Função

Ler

Gravar

gerenciar

Leia o escopo secreto

Listar segredos no escopo

Escreva para o escopo secreto

Modificar permissões

Servindo endpoint ACLs

Função

No Permissions

Pode ver

CAN QUERY

Can Manage (Pode gerenciar)

Obter endpoint

Lista endpoint

Endpoint da query

Atualizar a configuração do endpoint

Excluir endpoint

Modificar permissões

SQL warehouse ACLs

Função

No Permissions

Pode ver

PODE MONITORAR

Pode usar

É o proprietário

Can Manage (Pode gerenciar)

começar o armazém

ver detalhes do depósito

Consultas de visualização do depósito

execução de consultas

view warehouse monitoramento tab

Pare o armazém

Excluir o depósito

Edite o depósito

Modificar permissões

Pesquisa vetorial endpoint ACLs

Função

No Permissions

PODE CRIAR

Pode usar

Can Manage (Pode gerenciar)

Obter endpoint

Ponto de extremidade da lista

Criar endpoint

Usar endpoint (criar índice)

Excluir endpoint

Modificar permissões