Azure Databricks与ADLS Gen 2安全访问

Question

在我们这家小公司的团队中，我遇到了一些挫折，围绕着使用Azure Databricks中将Azure Databricks作为我们的增量表的后端（我是这家公司和Databricks的新手，所以我可能解释的任何事情都是在我之前决定的，我意识到其中一些可能是有问题的， 但不是寻找对此的看法）。

本质上，工程团队正在构建数据摄取管道(作为python文件，而不是笔记本)，这些管道在Azure Databricks (Jobs API)上运行并由它调度。这意味着管道必须能够访问ADLS第二代存储资源，因此我们直接使用服务主体(SPN)和OAuth 2.0进行身份验证，如本微软文档所述，通过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）中运行，并设置适当的存储帐户配置。也许是非常规的，但我们这边没有问题。

问题是：我们的数据科学团队在Database ricks Notebook上运行，并且还需要访问ADLS Gen 2支持的数据表——因此，他们也必须进行身份验证。然而，他们的代码不是工程代码，因此他们没有考虑环境的变化。因此，他们感到沮丧的是，在推广到生产环境时，他们必须做一个小调整，允许它在生产环境中工作，但在开发环境中不工作，因为这些环境在他们自己的VNET中，并且有自己的存储帐户。

问题：我们如何安全地允许表访问而不牺牲访问控制，并且不必在笔记本/代码库中设置这些配置？Databricks甚至可以做到这一点吗？

如果其他团队正在使用上述方法，他们如何在不破坏dev中的代码的情况下将容器升级到生产？这只是告诉DS团队他们必须使用我们的逻辑吗？

我尝试过的：

• ADLS 凭证直通 - 由于我们计划其模型使用数据砖作业 API 运行 - 这对凭证直通有硬性限制，因此无法使用
• 装载 ADLS - 由于这使有权访问群集的任何人都可以访问 ADLS，因此团队反对这种方法
• 集群配置（UI） - 我们将临时集群用于作业，但由于这将以明文形式列出任何检索到的机密，因此所有人都反对这种方法

目前，我已经在他们的笔记本中实现了工程团队的逻辑以检测环境，但我再怎么强调他们对工程代码在他们的笔记本中实现的愤怒也不为过。

我知道可能没有任何直截了当的答案，但任何帮助将不胜感激。

Answer 1

你是对的，没有一个单一的答案，而是一个折衷的选择。目前所有可用选项中最好的一个是这里，它详细解释了6种模式：

>

通过服务主体访问

多个工作区 — 按工作区划分的权限

AAD凭据传递

群集范围的服务主体

会话范围的服务主体

数据库表访问控制

您现在正在使用会话范围的服务主体，并为此支付管理开销。

我对您在团队和整体基础设施之间的工作流程有点困惑，但我首先会考虑的选项很少：

< li >使用小部件对笔记本进行html" target="_blank">参数化，以选择存储帐户并保持不同环境之间的机密命名一致(我假设您有由不同密钥库支持的dev和prd)尽可能多地提取样板逻辑，以分离可重复使用的笔记本 < li >在开发环境中为数据科学团队使用直通装载，在生产环境中使用相同名称的服务主体装载(假设生产环境受到更多限制和控制) < li >将数据科学家分离到具有工作区范围装载的独立工作区