Synapse Pipeline - 如何指定 Pipeline Run 的標識？ (SP/UAMI 等)

Question

我在受控的企業環境中使用 Synpase Spark Pools。 我查詢 AAD 的權限有限，但我可以創建 UAMI 並將它們分配給資源。

當我訪問我的 Synpase 工作區時，我可以創建一個 Spark 作業定義來從 ADLS 讀取一些數據。 查看 Monitor 選項卡下的 Apache Spark Applications 列表，我可以看到這些作業使用我的身份 (tim.davies@work.com) 作為“提交者”，並且由於我已經為自己授予了對數據存儲的 rx 訪問權限，所以這些工作成功了。

現在，如果我創建一個管道，並將其配置為運行我的 Spark 作業定義，它會因授權錯誤而失敗。 回到 Apache Spark Applications list under Monitor 我看到我的管道有一個不同的身份用作提交者，這可以解釋為什么它沒有被授權訪問數據。

首先，我不確定現在使用哪個身份作為提交者，我無法將 UUID 識別為我的 Synapse Workspace SAMI 或 UAMI（但我無法查詢 AAD 以獲取更多信息）。

但是總的來說，我突然想到我可能希望能夠為我的管道分配明確的 UAMI 以在其下運行。 這可能嗎？ 或者是否有不同的 model 來管理這個？

Answer 1

據我了解，這里的問題是了解如何從 Spark 作業中讀取來自 ADLS 的數據。 由於您可以訪問 ADLS，因此工作正常。 我認為您必須在 ADLS 上設置 Synapse 工作區的權限，它應該可以正常工作。

Answer 2

對此的更新速度稍慢，但我已經在理解方面找到了一些答案，如果不是一個解決方案的話。 對於關注或研究相同問題的任何人，在此處分享將很有用。

首先，當通過門戶/UI 訪問 Synapse 工作區時，筆記本或獨立“Apache Spark 作業定義”使用的可操作身份是登錄用戶的身份（通過“ AAD 直通”） . 這對用戶體驗非常有用，尤其是在 Notebooks 中，您只需要確保您作為個人對您使用的任何數據源都有個人訪問權限。 在某些情況下，如果您的用戶身份沒有此訪問權限，您可以改用Workspace 鏈接服務身份，但並非總是如此！ （繼續閱讀）

但是，一旦您切換到使用管道，所使用的標識就是工作區的系統分配托管標識 (SAMI) ，它是在資源創建時創建和分配的。 這沒關系，但了解粒度很重要，即。 有權訪問資源的是工作區，而不是單個管道。 因此，如果您想運行具有不同訪問級別的管道，您將需要將它們部署到隔離的 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 可以訪問所需的資源，並且您可以使用 go。如果您只是想實現它工作然后做這個並停在這里，但如果你想看得更深一點繼續......

某些Microsoft 文檔中的建議是，您應該能夠在 Spark 應用程序中使用工作區鏈接服務，以便訪問資源。 但這不起作用，我一直在與 Microsoft 討論相同的問題，他們已經確認並正在調查。 所以在這一點上值得注意的是日期（02/02/ 2023——對美國讀者來說很容易明確;-)），因為這個問題可能會在以后得到解決。 但是現在您在 Spark 代碼中的唯一選擇是退回到用戶/工作區身份。

只是想一想為什么這很重要，它並不是真正的隔離，因為工作區中運行的任何資源都可以訪問任何鏈接服務。 這實際上更像是身份和資源管理的問題，即。 最好將正在使用和分配給資源的身份與資源本身分開。 在大多數情況下，我們寧願對具有個人身份的組執行此操作，如果管理過程冗長（我的），那么我寧願不必在每次創建資源時都重復它們。

無論如何，現在就足夠了，如果在我仍在關注的情況下發生變化，將會更新...