Definir permissões para recursos no Databricks Asset Bundles
Este artigo descreve como definir permissões para trabalhos do Azure Databricks, pipelines de DLT e pilhas de MLOps no Databricks Asset Bundles. Consulte O que são Databricks Asset Bundles?.
Nos arquivos de configuração do pacote do Azure Databricks, você pode definir permissões para aplicar a todos os recursos definidos no pacote ou pode definir uma ou mais permissões para aplicar a recursos específicos.
Nota
As permissões não podem se sobrepor. Em outras palavras, as permissões para um utilizador, grupo ou entidade de serviço não podem ser definidas tanto no mapeamento ao nível permissions
superior como dentro do mapeamento resources
.
Definir permissões para aplicar a todos os recursos
Você pode definir permissões a serem atribuídas a todos os experimentos, trabalhos, modelos e pipelines definidos em resources
usando o mapeamento de nível superior permissions
. Consulte as permissões.
O Databricks recomenda essa abordagem para gerenciar permissões de recursos do Databricks Asset Bundles.
Definir permissões para um recurso específico
Você 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 utilizador, grupo ou 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:- Experiências:
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
. - Condutas:
CAN_MANAGE
,CAN_RUN
,CAN_VIEW
, eIS_OWNER
.
- Experiências:
Para obter informações sobre níveis de permissão específicos, consulte:
- Experimentos: ACLs de experimento MLflow
- Tarefas: Job ACLs
- Modelos: ACLs do modelo MLflow
- Pipelines: ACLs de pipelines DLT
Nota
Os níveis de permissão permitidos para recursos não podem necessariamente ser aplicados a recursos usando o mapeamento de nível permissions
superior. Para obter os níveis de permissão válidos para o permissions
mapeamento, consulte permissões.
A sintaxe a seguir mostra como declarar várias permissões para cada tipo de recurso, seja no mapeamento de nível resources
superior ou em um resources
mapeamento dentro de um destino (as reticências indicam conteúdo omitido, para 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 de nível resources
superior são combinadas com quaisquer permissões declaradas para esse mesmo resources
mapeamento em um destino individual. Por exemplo, dado o seguinte resources
mapeamento para o mesmo recurso tanto ao nível superior como num alvo (reticências indicam conteúdo omitido, para brevidade):
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_RUN
# ...
Ao executar databricks bundle validate
para este exemplo, o gráfico resultante é o seguinte (reticências indicam conteúdo omitido, para brevidade):
{
"...": "...",
"resources": {
"jobs": {
"my-job": {
"permissions": [
{
"level": "CAN_VIEW",
"user_name": "someone@example.com"
},
{
"level": "CAN_RUN",
"user_name": "someone@example.com"
}
],
"...": "..."
}
}
}
}