【发布时间】：2021-07-27 11:42:41
【问题描述】：
我们目前处于数据探索和生产作业（从生产工作流程运行）位于单个数据工作区的设置中。
生产作业都指 Databricks 工作区中特定文件夹中的笔记本，我们对其具有限制访问权限，并且此文件夹中的笔记本是使用 CI/CD 流程部署的。 Databricks 作业也是从同一个 CI/CD 管道创建的。基本上，作业以 json 格式描述，连接到数据湖（存储数据的地方）的身份验证信息是（动态）创建的集群信息的一部分。
这些作业的权限设置也是同一个 CI/CD 进程的一部分，它设置这些作业的权限，因此非管理员用户只有“查看”权限。
现在，一切都很好。
现在，“建议”非用户通过管道创建工作，但如果他们愿意，他们可以非常好地以临时方式自己创建工作，并且没有办法阻止他们这样做。 自己创造工作使他们成为所有者。结果，发生的事情是：他们可以“潜在地”复制相同的 spark 配置，该配置对数据湖中的策划区域具有“写入”权限，这是一个安全威胁。我们在数据湖中定义了 ACL，因此非管理员只能对“沙盒”文件系统进行写访问。
但是，由于他们可以查看生产作业的 spark 配置（他们有权查看），因此他们可以很好地复制相同的配置作为集群配置的一部分，用于他们可以的临时作业“可能创造”。
我现在决定为生产作业设置一个单独的工作区，以便实现职责分离。早些时候我们有这个，但后来进入 ML Flow 并回到过去，我们无法共享 MLFLow Registry，但现在我们可以了，这很棒。
但问题仍然是相同的用户仍然需要访问这个新工作区，因为我们希望他们自己监控作业。此外，他们需要访问权限才能从 CI/CD 管道中获取已部署作业的“job_id”，以便他们可以使用它来包含在 Airflow 管道中（我们从那里编排作业管道）。
所以，基本上回到那种“方形”（尽管我仍然想要一个单独的工作区用于生产工作）。
我看过这个，但这显然没有足够的票数（我仍然赞成这个）：here
只是举个例子，更清楚地说明我们的 repo 中如何定义作业以及如何定义 spark 配置，这些配置最终通过我们的 CI/CD 流程推出（在创建临时作业时可能会被复制）非管理员用户）-
{
"name": "ClientStateVector",
"new_cluster": {
"spark_version": "7.3.x-scala2.12",
"node_type_id": "Standard_F32s_v2",
"driver_node_type_id": "Standard_DS4_v2",
"num_workers": 3,
"spark_conf": {
"spark.hadoop.fs.azure.account.oauth2.client.endpoint.datalakename.dfs.core.windows.net": "https://login.microsoftonline.com/tenantid/oauth2/token",
"spark.databricks.delta.preview.enabled": "true",
"spark.hadoop.fs.azure.account.auth.type.datalakename.dfs.core.windows.net": "OAuth",
"spark.hadoop.fs.azure.account.oauth.provider.type.datalakename.dfs.core.windows.net": "org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider",
"spark.hadoop.fs.azure.account.oauth2.client.secret.datalakename.dfs.core.windows.net": "{{secrets/DatalakeKeySec/clientSecret}}",
"spark.hadoop.fs.azure.account.oauth2.client.id.datalakename.dfs.core.windows.net": "{{secrets/DatalakeKeySec/clientID}}"
}
},
"libraries": [
{ "whl": "dbfs:/artifacts/client-state-vector/1.0.47/client_state_vector-1.0.0-py3-none-any.whl" }
],
"notebook_task": {
"notebook_path": "/JobNotebooks/DataScienceNotebooks/ClientStateVector/bootstrap"
}
}
允许非管理员查看权限但仍确保他们无法使用相同的 spark 配置创建作业或根本无法创建作业的最佳方法是什么？
我知道拥有 webhook 是可能的，但它肯定必须更简单。还是我遗漏/不知道什么？
【问题讨论】：
标签： databricks azure-databricks