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.
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
, ouservice_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
eCAN_READ
. - Empregos:
CAN_MANAGE
,CAN_MANAGE_RUN
,CAN_VIEW
eIS_OWNER
. - Modelos:
CAN_EDIT
,CAN_MANAGE
,CAN_MANAGE_STAGING_VERSIONS
,CAN_MANAGE_PRODUCTION_VERSIONS
eCAN_READ
. - pipeline:
CAN_MANAGE
,CAN_RUN
,CAN_VIEW
, eIS_OWNER
.
- Experimentos:
Para obter informações sobre níveis de permissão específicos, consulte:
- Experimentos: ACLs de experimentos MLflow
- Empregos: Job ACLs
- Modelos: ACLs do modelo MLflow
- pipeline: DLT pipeline ACLs
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):
# ...
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:
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:
{
"...": "...",
"resources": {
"jobs": {
"my-job": {
"permissions": [
{
"level": "CAN_VIEW",
"user_name": "someone@example.com"
},
{
"level": "CAN_MANAGE_RUN",
"user_name": "someone@example.com"
}
],
"...": "..."
}
}
}
}