引言
在雲端與混合雲環境下，傳統的邊界防禦模型已無法滿足現代應用的安全需求。Shopify透過零信任架構（Zero Trust）實踐，結合Mutual TLS（MTLS）與機器身份管理，建立了一套可擴展且自動化的服務間認證系統。本文探討其技術核心、架構設計與實作策略，並分析如何在規模化部署中平衡安全與運維效率。
主要內容
技術定義與核心概念
Mutual TLS 是一種雙向認證機制，要求服務端與客戶端均需出示數位證書以驗證身份。在零信任架構中，Mutual TLS 作為服務間通訊的基礎，確保所有通信均經過身份驗證與加密。
Attested Identities 透過 X.509 證書與 Spiffy ID 格式（URI 結構如 spiffy://shopify.com/service-account/project）建立機器身份，確保每個服務均有唯一且可驗證的數位身分。Spiffy ID 的設計避免使用 @ 符號，並由實現者定義路徑，以適應不同場景。
CNCF（Cloud Native Computing Foundation） 提供的 Spire 作為參考實現，用於管理節點代理的證書生命週期，並整合 Google Certificate Authority Service（CAS）生成證書。此架構符合 CNCF 的雲原生標準，強化了跨雲端環境的可移植性。
關鍵特性與應用場景
- 自動化證書管理：透過 Google Secret Manager 儲存證書，並結合 Kubernetes Secret 進行整合。自訂工具支援 VM、Cloud Run 等非 Kubernetes 環境，確保證書自動續約與更新。
- ACL 與訪問控制：Spiffy ID 作為工作負載身分，透過 SAN URI 解析後注入 Kubernetes Secret，並與 ACL 機制結合，限制特定端點的存取權限。例如，服務 A 無權存取
/internal/Z 端點時會觸發拒絕存取。
- 混合儲存方案：支援本地檔案系統、Google Cloud Storage、Secret Manager 與 Kubernetes Secret 等四種儲存選項，需配合 IAM 權限與角色綁定。
- 序列化部署與可觀察性：使用 Argo CD Sync Waves 管理資源部署順序，確保命名空間先於 Job 部署，Job 先於 Deployment 部署。證書載入流程透過初始 Job 掛載 Kubernetes Secret，並定期 Job 處理更新，避免服務啟動失敗。
實作案例與挑戰
- Spire 與 Google CAS 整合：透過 Identity Reflection 獲取 Spiffy ID，並利用 Google Cloud 集成生成證書。此方案解決了 Kafka 預設使用 Distinguished Name（DN）進行 ACL 控制的問題，需自訂 Kafka 原則建構器解析 SAN URI。
- 證書生命週期管理：採用三層 PKI 架構（Root CA、Intermediate CA、Leaf Certificates），並設定自動化輪換策略。Root CA 提前三年輪換，Intermediate CA 提前三個月輪換，透過警報與驗證流程確保平滑過渡。
- 動態排程與異常監控：為每個服務生成獨特的 Cron 表達式，透過服務名稱作為鹽值計算，避免萬服務同時請求導致併發問題。證書剩餘壽命達 50% 時觸發續約，並透過 Prometheus Push Gateway 收集 Jobs 指標，使用 StatsD 即時推送資料至 Prometheus。
技術優勢與挑戰
優勢：
- 強化安全性：透過 MTLS 確認服務身份，結合 Spiffy ID 與證書管理解決機器身份複雜性。
- 可擴展性：自動化證書管理與部署順序控制，適應 Shopify 百萬 Pod 級規模。
- 靈活性：支援多種儲存選項與自訂解析邏輯，適應不同雲端與本地環境。
挑戰：
- 維護成本：需維護額外控制平面（如 Service Mesh）或自訂解析邏輯，增加運維複雜度。
- 效能考量：證書驗證與 ACL 檢查可能增加 CPU/記憶體負擔，需優化解析流程。
- 依賴性風險：Google Cloud 集成可能導致 vendor lock-in，需評估跨雲端遷移可行性。
總結
Shopify 的零信任架構透過 MTLS 自動化管理，實現了服務間的強制認證與訪問控制。其核心在於結合 Spiffy ID、CNCF 工具（如 Spire）與 PKI 架構，解決機器身份管理與證書生命週期的挑戰。在規模化部署中，需平衡安全、效能與運維成本，選擇合適的認證方案（如 Ingress Engine X 自訂解析）與自動化策略。未來可進一步優化證書輪換機制與異常監控，以提升系統穩定性與可觀察性。