Festlegen von Berechtigungen für Ressourcen in Databricks-Ressourcenpaketen
In diesem Artikel wird beschrieben, wie Sie Berechtigungen für Azure Databricks-Aufträge, Delta Live Tables-Pipelines und MLOps-Stapel in Databricks-Ressourcenpaketen festlegen. Weitere Informationen finden Sie unter Was sind Databricks-Ressourcenpakete?.
In Paketkonfigurationsdateien von Azure Databricks können Sie Berechtigungen definieren, die für alle im Paket definierten Ressourcen gelten sollen. Oder Sie können eine oder mehrere Berechtigungen definieren, die für bestimmte Ressourcen gelten sollen.
Hinweis
Berechtigungen dürfen sich nicht überlappen. Mit anderen Worten: Berechtigungen für einen Benutzer/eine Benutzerin, eine Gruppe oder einen Dienstprinzipal können nicht sowohl in der permissions
-Zuordnung der obersten Ebene als auch innerhalb der resources
-Zuordnung definiert werden.
Definieren von Berechtigungen, die für alle Ressourcen gelten sollen
Sie können Berechtigungen definieren, die für alle Experimente, Aufträge, Modelle und Pipelines gelten sollen, die in resources
mithilfe der permissions
-Zuordnung auf oberster Ebene definiert werden. Weitere Informationen finden Sie unter Berechtigungen.
Definieren von Berechtigungen für eine bestimmte Ressource
Sie können das permissions
-Array in einer Experiment-, Auftrags-, Modell- oder Pipelinedefinition in resources
verwenden, um eine oder mehrere Berechtigungen für diese Ressource zu definieren.
Jede Berechtigung im permissions
-Array muss die folgenden beiden Zuordnungen enthalten:
- Entweder
user_name
,group_name
oderservice_principal_name
mit dem Namen des Benutzers, der Gruppe oder des Dienstprinzipals. level
mit dem Namen der Berechtigungsstufe. Folgende Berechtigungsstufen sind für die einzelnen Ressourcen zulässig:- Experimente:
CAN_EDIT
,CAN_MANAGE
undCAN_READ
. - Aufträge:
CAN_MANAGE
,CAN_MANAGE_RUN
,CAN_VIEW
undIS_OWNER
. - Modelle:
CAN_EDIT
,CAN_MANAGE
,CAN_MANAGE_STAGING_VERSIONS
,CAN_MANAGE_PRODUCTION_VERSIONS
undCAN_READ
. - Pipelines:
CAN_MANAGE
,CAN_RUN
,CAN_VIEW
undIS_OWNER
.
- Experimente:
Informationen zu bestimmten Berechtigungsstufen finden Sie unter:
- Experimente: MLFlow Experiment ACLs
- Aufträge: Auftrags-ACLs
- Modelle: MLFlow-Modell ACLs
- Pipelines: Delta Live Tables ACLs
Die folgende Syntax zeigt, wie sie mehrere Berechtigungen pro Ressourcentyp deklarieren, entweder in der resources
-Zuordnung auf oberster Ebene oder einer resources
-Zuordnung innerhalb eines Ziels (Auslassungspunkte geben ausgelassenen Inhalt aus Platzgründen an):
# ...
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>
# ...
# ...
Alle Berechtigungen, die für eine Ressource in der resources
-Zuordnung auf oberster Ebene deklariert sind, werden mit allen Berechtigungen kombiniert, die für dieselbe resources
-Zuordnung in einem einzelnen Ziel deklariert sind. Sehen Sie sich als Beispiel die folgende resources
-Zuordnung für dieselbe Ressource auf oberster Ebene und in einem Ziel an (Auslassungspunkte geben ausgelassenen Inhalt aus Platzgründen an):
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
# ...
Wenn Sie für dieses Beispiel databricks bundle validate
ausführen, sieht der resultierende Graph wie folgt aus (Auslassungspunkte weisen auf Inhalte hin, die der Übersichtlichkeit halber weggelassen wurden):
{
"...": "...",
"resources": {
"jobs": {
"my-job": {
"permissions": [
{
"level": "CAN_VIEW",
"user_name": "someone@example.com"
},
{
"level": "CAN_RUN",
"user_name": "someone@example.com"
}
],
"...": "..."
}
}
}
}