安全地將 GitHub Actions 連接到 Azure Machine Learning

你的驗證工作流程現在可以在程式碼錯誤到達 main 之前攔截它們。 下一步是讓這些工作流程與 Azure Machine Learning 溝通——提交工作、讀取結果並註冊模型。 這需要驗證，而你如何處理它對安全性很重要。

祕密與變數

GitHub 提供兩個存放工作流程配置的地方：

• 秘密 是用於憑證及其他敏感設定的加密值。 GitHub 會掩蓋日誌中的秘密值，但工作流程仍必須避免暴露這些值。
• 變數用於儲存非敏感設定。 用它們來命名工作區名稱、資源群組名稱，以及你想在工作流程中重複使用的類似值。

環境範圍的秘密比存放庫機密更狹窄：作業必須先針對該環境才能存取。

服務負責人與最低特權

一種將工作流程認證到 Azure 的方法是使用服務主體——Microsoft Entra ID 中的非人類身份。 你建立主體，指派 Azure 角色，並將憑證存為 GitHub 秘密。

角色和範圍很重要。 在工作流程需要的最狹窄範圍內指定適當的角色，例如 Azure Machine Learning 工作空間或其資源群組。

使用 OpenID Connect 的工作負載身分同盟

將長效的憑證儲存為秘密存在風險：如果秘密被揭露，它會持續有效直到你輪替它。 使用 OpenID Connect (OIDC) 的 工作負載身分同盟可避免儲存該長期有效的憑證。

你不是儲存客戶端秘密，而是設定 GitHub 倉庫與 Microsoft Entra 應用程式之間的信任關係。 當工作流程執行時，GitHub 會發出一個短暫的 OIDC 令牌。 Azure 會驗證該憑證並回傳一個存取憑證——不會交換儲存的憑證。

工作流程驗證與 Git 追蹤

當你從本地 Git 儲存庫提交原始檔案時，Azure Machine Learning 可以記錄儲存庫、分支，並提交訓練工作。 這個追蹤功能適用於任何相容的 Git 服務，且不會將特定的 GitHub 倉庫附加到工作區。

Git 追蹤和工作流程驗證解決了不同的問題。 追蹤會將工作與產生該工作的原始版本連結起來。 驗證會授予工作流程提交該作業的權限。