对此的更新速度稍慢，但我已经在理解方面找到了一些答案，如果不是一个解决方案的话。对于关注或研究相同问题的任何人，在此处分享将很有用。
首先，当通过门户/UI 访问 Synapse 工作区时，笔记本或独立“Apache Spark 作业定义”使用的可操作身份是登录用户的身份（通过“AAD Passthrough” ).这对用户体验非常有用，尤其是在 Notebooks 中，您只需要确保您作为个人对您使用的任何数据源都有个人访问权限。在某些情况下，如果您的用户身份没有此访问权限，您可以使用工作区关联服务相反，但并非总是如此！ （继续阅读）
但是，一旦您切换到使用 Pipelines，所使用的身份是 System Assigned Managed Identity (SAMI) of the workspace，它是在资源创建时创建和分配的。这没关系，但了解粒度很重要，即。有权访问资源的是工作区，而不是单个管道。因此，如果您想运行具有不同访问级别的管道，您将需要将它们部署到隔离的 Synapse 工作区（具有不同的 SAMI）。
除了这一点之外，还有“提交者' 我在最初的问题中提到过，它在所有 Apache Spark 应用程序的 Synapse 工作区的监视器选项卡下可见。当以用户（例如 Notebooks）身份运行时，此提交者 ID 是我的 AAD 用户名，这很简单。但是，当作为管道运行时，提交者 ID 为 'ee20d9e7-6295-4240-ba3f-c3784616c565'，我的意思是字面意思是相同的 UUID每个人.原来这是ADF作为企业应用的id。例如，与将 Workspace SAMI 放在这里相比，这不是很有用，但这就是万一其他人掉进那个兔子洞的情况！
您可以创建一个额外的用户分配托管身份 (UAMI) 并将其分配给工作区，但这不会被执行管道使用。 UAMI 可由 Workspace 链接服务使用，但它有一些自身的限制（如下所述）。另外我的经验是，在创建工作区时分配的 UAMI 将无法正确“关联”到工作区，直到我在门户中手动创建第二个 UAMI。我没有深入研究这个问题，因为 UAMI 对我没有好处，但似乎是一个简单的错误。
现在我的具体用例是在 Synapse Pipelines 中运行 Apache Spark 应用程序，完成这项工作的直接方法是确保 Workspace SAMI 可以访问所需的资源，并且您可以开始了。如果你只是想让它工作，那么这样做并停在这里，但如果你想看得更深一点，请继续......
Microsoft documentation 中的一些建议是您应该能够在 Spark 应用程序中使用工作区链接服务以访问资源。但这不起作用，我一直在与 Microsoft 讨论相同的问题，他们已经确认并正在调查。所以在这一点上值得注意的是日期（02/02/2023- 对美国读者来说毫不含糊 ;-))，因为这个问题以后可能会得到解决。但是现在您在 Spark 代码中的唯一选择是退回到用户/工作区身份。
只是想一想为什么这很重要，它并不是真正的隔离，因为工作区中运行的任何资源都可以访问任何链接服务。这实际上更像是身份和资源管理的问题，即。最好将正在使用和分配给资源以供访问的身份与资源本身分开。在大多数情况下，我们宁愿对具有个人身份的组执行此操作，如果管理过程冗长（我的），那么我宁愿不必在每次创建资源时都重复它们。
无论如何，现在就足够了，如果在我仍在关注的情况下发生变化，将会更新...