工作流程執行權限是怎麼運作的？我用一條真實的倉庫把它講清楚

為什麼工作流程執行權限比您想像的更重要

自動化工作流程（無論是 CI/CD 管道、資料處理作業或基礎設施配置）都取決於權限來決定允許哪些操作。但權限通常被視為事後的想法：設定一次然後就被忘記了。這種方法一直有效，直到管道中途失敗，或者更糟的是，惡意行為者利用了過度特權的令牌。

考慮一個典型場景：開發人員將程式碼推送到儲存庫，觸發 CI 管道建置 Docker 映像並將其推送到註冊表，然後部署到臨時伺服器。每個步驟都需要不同的權限 - 對儲存庫的讀取存取權、對登錄機碼的寫入權限以及對登台伺服器的 SSH 存取權。如果這些權限中的任何一個配置錯誤，管道都會默默地失敗或暴露秘密。

工作流程執行權限不僅僅是「誰可以運行工作流程」。它們包括：

• 哪些身分（使用者、服務帳號、系統）可以啟動執行。
• 工作流程在執行期間可以存取哪些資源。
• 允許工作流程對這些資源執行哪些操作。

挑戰在於這些權限跨多個系統級聯：原始碼控制、工件儲存庫、運算環境和機密管理。單一錯誤配置的令牌可能會停止整個部署。

具體場景：週五失敗的分期部署

讓我們舉一個真實的例子。 Sarah 是一家金融科技新創公司的開發營運工程師。她設定了一個 GitHub Actions 工作流程：

1. 推送到 main 時，建立一個 Node.js 應用程式。
2. 運行單元測試。
3. 將 Docker 映像推送到 AWS ECR。
4. 透過 kubectl 部署到 Kubernetes 臨時叢集。

為了運行工作流程，她使用有權推送 ECR 和更新 Kubernetes 部署的 IAM 使用者建立了 GitHub Actions 金鑰 AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY。

一切都可以持續數週。然後在一個星期五，一位隊友推送了一個小更改，工作流程在第 3 步失敗，並出現「AccessDenied」錯誤。 Sarah 檢查了 IAM 用戶——沒有任何變化。 AWS 的秘密仍然存在。發生了什麼事？

問題：作為例行合規性掃描的一部分，安全團隊輪換了 IAM 使用者的金鑰，但 GitHub 金鑰並未更新。工作流程嘗試使用無效金鑰但失敗。

這是一種經典的故障模式：由外部變更引起的權限漂移。工作流程本身沒有改變，但底層憑證發生了變化。由於沒有人注意到旋轉，管道破裂了幾個小時。

為什麼工作流程執行權限失敗

除了憑證漂移之外，其他常見的故障模式包括：

• 過於廣泛的權限：使用授予無限制存取權限的管理員級服務帳戶。如果工作流程受到損害，這會增加爆炸半徑。
• 缺乏範圍：僅需要一個儲存庫時授予對所有儲存庫的寫入存取權限。
• 硬編碼秘密：將 API 金鑰嵌入到日誌中公開的程式碼或工作流程檔案中。
• 缺少 OIDC 或代幣交換：依賴長期憑證而不是可以動態發行的短期代幣。

在我們的場景中，解決方案可能是將 AWS 的 OIDC 提供者與 GitHub Actions 結合使用，該提供者為每個作業頒發短期令牌並消除了對靜態金鑰的需求。但如果目標平台不支援 OIDC，這並不總是可行。

實用路徑：實現最低權限工作流程權限

為避免週五晚上停電，請按照以下步驟操作：

1. 對應每個資源存取權：對於每個工作流程步驟，列出確切的 API 呼叫和資源。對於我們的範例：repo 上的 ecr:PutImage、叢集上的 eks:UpdateClusterConfig 以及對儲存庫的讀取存取權。

2. 盡可能使用 OIDC：GitHub Actions、GitLab CI 和許多其他支援 OIDC。這將工作流程身分與儲存庫和分支連結起來，發出作用範圍為操作的短期令牌。

3. 範圍服務帳戶：如果 OIDC 不可用，請為每個工作流程或每個環境建立專用服務帳戶。避免重複使用單一管理員帳戶。

4. 自動憑證輪換：使用秘密管理器（AWS Secrets Manager、HashiCorp Vault）自動輪換金鑰並透過 API 將更新推送到工作流程提供者。

5. 測試權限管道：編寫整合測試來驗證每個步驟是否可以存取其所需的資源。這可以在部署之前捕獲漂移。

就 Sarah 的情況而言，切換到 O​​IDC 將消除硬編碼的 AWS 金鑰。只有當 OIDC 提供者本身發生故障（這種情況很少發生）且憑證每小時自動輪調時，工作流程才會失敗。

權限中斷時會發生什麼事？後果和恢復

當工作流程執行權限失敗時，直接的症狀是管道故障。但真正的成本是時間：開發人員等待修復、部署視窗關閉、利害關係人失去信心。

恢復計劃：

• 制定回滾策略：將工作流程還原到已知良好的版本或切換到手動部署。
• 使用後備身分：如果主服務帳戶發生故障，則觸發警報並回退到具有相同範圍的輔助帳戶（僅用於緊急情況）。
• 進行事後分析：更新權限文件、輪換憑證並新增對權限過期的監控。

複雜環境的替代方法

如果您的組織有多個團隊或複雜的合規性要求，請考慮：

• 工作流程級 RBAC：某些工作流程引擎（例如 Apache Airflow）提供基於角色的存取控制來限制誰可以觸發或修改工作流程。
• 策略即程式碼：OPA（開放策略代理程式）等工具可以在執行時強制執行權限，動態阻止未經授權的操作。
• 單獨的工作流程環境：對開發、登台和生產使用不同的憑證。切勿允許從 main 執行的工作流程存取生產環境，除非它通過了所有檢查。

每種方法都需要權衡。 RBAC 增加了配置開銷。策略即程式碼需要學習新的 DSL。獨立的環境意味著需要管理更多的秘密。根據您的團隊規模和合規性需求進行選擇。

最後的想法

工作流程執行權限是可靠自動化的關鍵。它們不僅涉及安全性，還直接影響正常運作時間。精心設計的權限模型可以減少故障、簡化調試並縮短恢復時間。

如果您正在建立 CI/CD 管道、資料工作流程或任何自動化系統，請預先投入時間來設計每個執行上下文的權限。使用 OIDC 或短期代幣，自動輪換並定期測試。你的周五晚上會感謝你的。