【发布时间】：2020-12-02 17:51:14
【问题描述】：
我的小公司的团队在使用 Azure Data Lake Storage Gen 2 作为 Azure Databricks 中增量表的后端时遇到了一些挫折（我是这家公司和 Databricks 的新手，所以我可以解释的任何事情都是在我的时间之前决定的，我意识到其中一些可能是有问题的，但不是在寻找观点）。
本质上，工程团队正在构建在 Azure Databricks (Jobs API) 上运行并由其安排的数据摄取管道（作为 python 文件，而不是笔记本）。这意味着管道必须能够访问 ADLS Gen 2 存储资源 - 因此我们直接使用服务主体 (SPN) 和 OAuth 2.0 进行身份验证，如 Microsoft doc 中所述，通过 spark.conf.set 设置以下配置():
fs.azure.account.auth.type.[STORAGE_ACCT].dfs.core.windows.net
fs.azure.account.oauth.provider.type.[STORAGE_ACCT].dfs.core.windows.net
fs.azure.account.oauth2.client.id.[STORAGE_ACCT].dfs.core.windows.net
fs.azure.account.oauth2.client.secret.[STORAGE_ACCT].dfs.core.windows.net
fs.azure.account.oauth2.client.endpoint.[STORAGE_ACCT].dfs.core.windows.net
鉴于工程部门正在为我们的管道使用此功能，并且我们为 dev/prod 使用不同的存储帐户，代码库会检测我们在哪个环境（dev 或 prod）中运行并设置适当的存储帐户配置。也许非常规，但我们这边没有问题。
问题： 我们的数据科学团队在 Databricks Notebooks 上运行，并且还需要访问由 ADLS Gen 2 支持的数据表 - 因此，他们也必须进行身份验证。但是，他们的代码不是工程代码，所以他们没有考虑环境的变化。因此，他们感到沮丧的是，在升级到生产环境时，他们必须进行一些小调整，使其能够在 prod 中运行，但在 dev 中无法运行，因为这些环境在它们自己的 VNET 中并且有自己的存储帐户。
询问： 我们如何安全地允许表访问而不牺牲访问控制，并且不必在笔记本/代码库中设置这些配置？使用 Databricks 是否也能做到这一点？
如果其他团队正在使用上述方法，他们如何在不破坏开发代码的情况下将容器升级到生产？只是告诉 DS 团队他们必须使用我们的逻辑吗？
我的尝试：
- ADLS 凭据直通 - 因为我们安排他们的模型使用 Databricks 作业 API 运行 - 这对凭据直通有严格限制，因此无法使用
- 挂载 ADLS - 由于这使任何有权访问集群的人都可以访问 ADLS，因此团队反对这种方法
- 集群配置 (UI) - 我们将临时集群用于作业，但由于这会以明文形式列出所有检索到的机密，因此所有人都反对这种方法
目前，我已经在他们的笔记本中实现了工程团队的逻辑以检测环境，但我无法强调他们对在他们的笔记本中实现工程代码的热情。
我知道可能没有直接的答案，但我们将不胜感激。
【问题讨论】：
标签： azure azure-databricks access-control azure-data-lake-gen2