Databricks アセット バンドル内のリソースに対するアクセス許可を設定する
この記事では、Databricks Asset Bundles のリソースのアクセス許可を設定する方法について説明します。詳細については、 リソース バンドルでサポートされているリソースについては、「 Databricks Asset Bundles リソース」を参照してください。
Databricks バンドル構成ファイルでは、バンドルで定義されているすべてのリソースに適用するアクセス許可を最上位レベルで定義することも、特定のリソースに適用するアクセス許可を定義することもできます。
権限は重複できません。 つまり、ユーザー、グループ、またはサービスプリンシパルの権限は、最上位の permissions
マッピングと resources
マッピングの両方で定義することはできません。
すべてのリソースに適用する権限を定義する
トップレベルのpermissions
マッピングを使用して、resources
で定義されているすべてのサポートされているリソースに適用する権限を定義できます。Databricks では、Databricks Asset Bundles リソースのアクセス許可を管理するために、このアプローチをお勧めします。
権限は、 user_name
、 group_name
、または service_principal_name
に許可される権限レベルを定義します。許可される最上位の権限レベルは、 CAN_VIEW
、 CAN_MANAGE
、および CAN_RUN
です。詳細については、 情報 トップレベルの permissions
マッピングについては、「 権限」を参照してください。
次の例では、 dev
ターゲットの最上位のアクセス許可を設定します。ユーザーsomeone@example.com
には、my-job
に対するCAN_RUN
権限があります。
bundle:
name: my-bundle
resources:
jobs:
my-job:
# ...
targets:
dev:
# ...
permissions:
- user_name: someone@example.com
level: CAN_RUN
特定のリソースに対する権限を定義する
resources
のダッシュボード、エクスペリメント、ジョブ、モデル、またはパイプライン定義のpermissions
マッピングを使用して、そのリソースに対する 1 つ以上の権限を定義できます。
permissions
マッピングの各権限には、次のものが含まれている必要があります。
user_name
、group_name
、またはservice_principal_name
のいずれかを、それぞれユーザー、グループ、またはサービスプリンシパルの名前に設定します。level
を権限レベルの名前に設定します。各リソースに許可される権限レベルは次のとおりです。
リソースに許可される権限レベルは、トップレベル permissions
マッピングを使用するリソースに必ずしも適用できるとは限りません。トップレベル permissions
マッピングの有効なアクセス許可レベルについては、「 アクセス許可」を参照してください。
次の構文は、最上位の resources
マッピングとターゲット内の resources
マッピングでリソースの種類 (この例ではパイプライン) のアクセス許可を宣言する方法を示しています。
# ...
resources:
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:
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>
# ...
# ...
最上位の resources
マッピングのリソースに対して宣言されている権限は、個々のターゲットの同じ resources
マッピングに対して宣言されている権限と組み合わされます。たとえば、トップレベルとターゲットの両方で同じリソースに対して次の resources
マッピングがあるとします。
bundle:
name: my-bundle
resources:
jobs:
my-job:
# ...
permissions:
- group_name: test-group
level: CAN_VIEW
# ...
targets:
dev:
# ...
resources:
jobs:
my-job:
# ...
permissions:
- user_name: someone@example.com
level: CAN_MANAGE_RUN
# ...
この例で databricks bundle validate
を実行すると、結果のグラフは次のようになります。
{
"...": "...",
"resources": {
"jobs": {
"my-job": {
"permissions": [
{
"level": "CAN_VIEW",
"group_name": "test-group"
},
{
"level": "CAN_MANAGE_RUN",
"user_name": "someone@example.com"
}
],
"...": "..."
}
}
}
}
権限の優先順位
バンドル構成の複数の場所で permissions
を定義している場合、バンドルで指定されたリソース、ワークスペースディレクトリ、およびファイルに付与される権限は、次の順序になります。
- ターゲット・デプロイメントのリソースに対して定義されている権限
- ターゲットデプロイに対して定義されたアクセス許可
- バンドル内のリソースに対して定義されているアクセス許可
- バンドルの最上位の権限で定義されている権限
たとえば、次の構成では、グループ ID test-group
は dev
ターゲットのジョブに対して CAN_MANAGE
のアクセス許可を持ちますが、prod
ターゲットのジョブに対するアクセス許可はCAN_MANAGE_RUN
ます。
bundle:
name: my-bundle
permissions:
- group_name: test-group
level: CAN_VIEW
resources:
jobs:
my-job:
# ...
permissions:
- group_name: test-group
level: CAN_MANAGE_RUN
# ...
targets:
dev:
# ...
resources:
jobs:
my-job:
# ...
permissions:
- group_name: test-group
level: CAN_MANAGE
# ...
prod:
# ...
resources:
jobs:
my-job:
# ...