Pular para o conteúdo principal

Definir permissões para recurso em Databricks ativo Bundles

Este artigo descreve como definir permissões para Databricks Job, DLT pipeline e MLOps Stacks em Databricks ativo Bundles. Veja o que são Databricks ativo Bundles?

Nos Databricks arquivos de configuração do pacote, o senhor pode definir permissões a serem aplicadas a todos os recursos definidos no pacote ou pode definir uma ou mais permissões a serem aplicadas a recursos específicos.

nota

As permissões não podem se sobrepor. Em outras palavras, as permissões para um usuário, grupo ou entidade de serviço não podem ser definidas no mapeamento de nível superior permissions e no mapeamento resources.

Definir permissões a serem aplicadas a todos os recursos

O senhor pode definir permissões a serem aplicadas a todos os experimentos, trabalhos, modelos e pipelines definidos em resources usando o mapeamento permissions de nível superior. Os níveis de permissão de nível superior permitidos são CAN_VIEW, CAN_MANAGE e CAN_RUN.

Para obter mais informações sobre o mapeamento permissions de nível superior, consulte as permissões.

Databricks recomenda essa abordagem para gerenciar as permissões de recurso do Databricks ativo Bundles.

Definir permissões para um recurso específico

O senhor pode usar o mapeamento permissions em uma definição de experimento, trabalho, modelo ou pipeline em resources para definir uma ou mais permissões para esse recurso.

Cada permissão no mapeamento permissions deve incluir os dois mapeamentos a seguir:

  • Ou user_name, group_name, ou service_principal_name, com o nome do usuário, do grupo ou da entidade de serviço, respectivamente.
  • level, com o nome do nível de permissão. Os níveis de permissão permitidos para cada recurso são os seguintes:
    • Experimentos: CAN_EDIT, CAN_MANAGE e CAN_READ.
    • Empregos: CAN_MANAGE, CAN_MANAGE_RUN, CAN_VIEW e IS_OWNER.
    • Modelos: CAN_EDIT, CAN_MANAGE, CAN_MANAGE_STAGING_VERSIONS, CAN_MANAGE_PRODUCTION_VERSIONS e CAN_READ.
    • pipeline: CAN_MANAGE, CAN_RUN, CAN_VIEW, e IS_OWNER.

Para obter informações sobre níveis de permissão específicos, consulte:

nota

Os níveis de permissão permitidos para recurso não podem necessariamente ser aplicados a recurso usando o mapeamento de nível superior permissions. Para obter níveis de permissão válidos para o mapeamento permissions, consulte permissões.

A sintaxe a seguir mostra como declarar várias permissões para cada tipo de recurso, seja no mapeamento resources de nível superior ou em um mapeamento resources dentro de um destino (as elipses indicam conteúdo omitido, para fins de brevidade):

YAML
# ...
resources:
experiments:
<some-programmatic-identifier-for-this-experiment>:
# ...
permissions:
- user_name: <user-name> # Or:
group_name: <group-name> # Or:
service_principal_name: <service-principal-name>
level: <permission-level>
# ...
jobs:
<some-programmatic-identifier-for-this-job>:
# ...
permissions:
- user_name: <user-name> # Or:
group_name: <group-name> # Or:
service_principal_name: <service-principal-name>
level: <permission-level>
# ...
models:
<some-programmatic-identifier-for-this-model>:
# ...
permissions:
- user_name: <user-name> # Or:
group_name: <group-name> # Or:
service_principal_name: <service-principal-name>
level: <permission-level>
# ...
pipelines:
<some-programmatic-identifier-for-this-pipeline>:
# ...
permissions:
- user_name: <user-name> # Or:
group_name: <group-name-1> # Or:
service_principal_name: <service-principal-name>
level: <permission-level>
# ...

targets:
<some-programmatic-identifier-for-this-target>:
resources:
experiments:
<some-programmatic-identifier-for-this-experiment>:
# ...
permissions:
- user_name: <user-name> # Or:
group_name: <group-name> # Or:
service_principal_name: <service-principal-name>
level: <permission-level>
# ...
jobs:
<some-programmatic-identifier-for-this-job>:
# ...
permissions:
- user_name: <user-name> # Or:
group_name: <group-name> # Or:
service_principal_name: <service-principal-name>
level: <permission-level>
# ...
models:
<some-programmatic-identifier-for-this-model>:
# ...
permissions:
- user_name: <user-name> # Or:
group_name: <group-name> # Or:
service_principal_name: <service-principal-name>
level: <permission-level>
# ...
pipelines:
<some-programmatic-identifier-for-this-pipeline>:
# ...
permissions:
- user_name: <user-name> # Or:
group_name: <group-name> # Or:
service_principal_name: <service-principal-name>
level: <permission-level>
# ...
# ...

Todas as permissões declaradas para um recurso no mapeamento resources de nível superior são combinadas com todas as permissões declaradas para o mesmo mapeamento resources em um destino individual. Por exemplo, dado o seguinte mapeamento resources para o mesmo recurso no nível superior e em um destino:

YAML
bundle:
name: my-bundle

resources:
jobs:
my-job:
# ...
permissions:
- user_name: someone@example.com
level: CAN_VIEW
# ...

targets:
dev:
# ...
resources:
jobs:
my-job:
# ...
permissions:
- user_name: someone@example.com
level: CAN_MANAGE_RUN
# ...

Quando o senhor executa databricks bundle validate para este exemplo, o gráfico resultante é o seguinte:

JSON
{
"...": "...",
"resources": {
"jobs": {
"my-job": {
"permissions": [
{
"level": "CAN_VIEW",
"user_name": "someone@example.com"
},
{
"level": "CAN_MANAGE_RUN",
"user_name": "someone@example.com"
}
],
"...": "..."
}
}
}
}