作業安全性對於維護對 Kubernetes 叢集的控制以及響應新興威脅非常重要。 本文涵蓋管理存取權、強制執行原則、監視活動及回應事件的最佳做法。 藉由實作強作控件,您可以協助確保只有已授權的使用者和程式可以變更叢集和工作負載。
控制誰可以使用 Azure 控制平面來管理您的叢集
控制對 Azure 控制平面的存取非常重要,包括可讓您對邊緣叢集進行 Azure Arc 雲端管理的訂用帳戶與相關資源。 檢閱並實作 Azure 訪問控制最佳做法,包括多重要素驗證和條件式存取。 使用 Azure RBAC 來控制誰可以對哪些叢集執行哪些操作,就像您已經用來控制其他 Azure 雲端資源的存取權一樣。
此外,Microsoft產生的憑證可用來協助保護邊緣叢集與 Azure 控制平面之間的連線。 這些憑證會儲存為 Kubernetes 秘密,因此 Kubernetes 秘密存放區本身必須加密。
藉由角色型存取控制(RBAC)來控制誰能夠部署到您的叢集
控制 Kubernetes 控制平面 (API 伺服器) 本身的存取也很重要,這是您可以部署和監視 Kubernetes 工作負載的方式。
對於工作負載向 API 伺服器的非人員存取,請使用 Kubernetes 內建的 RBAC,只授權那些真正需要的特定服務帳戶。 另請參閱 發行和保護這些服務帳戶的建議。
若要讓人類存取 API 伺服器,Kubernetes 沒有內建的用戶帳戶。 因此,我們建議將其與外部用戶帳戶服務整合,例如Microsoft Entra ID。 然後,您可以建立授權原則,使用這些身分識別來控制誰可以執行哪些命名空間。 您可以使用 Kubernetes 的內建 RBAC 或使用 Azure RBAC 來撰寫這些原則。 如果您想要在一個集中位置一致地管理和稽核所有使用者授權原則,涵蓋您的雲端和邊緣資源,建議使用 Azure RBAC。 如果您在 Azure Local 上執行透過 Azure Arc 啟用的 AKS (部分內容可能是機器或 AI 翻譯),或是如果您連線自己的叢集,就能輕鬆使用 Azure RBAC。 然後,您的使用者可以使用其 Entra ID 帳戶,直接或透過 Azure Proxy 使用「叢集連線」功能來存取叢集(其 API 伺服器)。 我們建議採用「最低許可權」方法,將每位使用者或工作負載指派具有所需最低許可權的角色。
更普遍地,請遵循分隔開發、測試和生產叢集的標準最佳做法。 並考慮使用 GitOps 方法,將更可靠且安全地管理叢集的生產部署。 如果您採用此方法,那麼對於用來定義部署的基礎來源 Git 存放庫及其分支上的變更 (提取要求),也同樣務必要實作強而有力的角色型存取控制。
最後,如果您要在 Azure 本機上執行 Azure Arc 所啟用的 AKS,您也可以 下載系統管理客戶端憑證,以取得完整的系統管理員存取權。 通常不需要使用此憑證,因此只有在需要時才下載它:例如,診斷無法以任何其他方式調查的問題。 您也應該謹慎使用此方法,因為它不會使用 Entra ID 帳戶,也不會應用您所設定的每位用戶的政策。 此外,您必須仔細儲存用戶端憑證,然後在不再需要時刪除。
參考資料
- CIS Kubernetes 基準 - 第 1、2 和 4 節 (英文)
- NIST 應用程式容器安全性指南 - 第 4.5.1-3 節
- NSA Kubernetes 強化指引 –「驗證和授權」
- Kubernetes 安全性 - OWASP 速查表系列 - 「控制 Kubernetes API 的存取權」
使用適用於 Kubernetes 的 Azure 原則部署和執行容器時,請遵循安全的容器生命週期
在部署階段,繼續遵循 Microsoft 容器安全供應鏈架構 (部分內容可能是機器或 AI 翻譯)。 (另請參閱 取得、目錄和建置階段的指引。此架構可協助您僅從自己的受信任登錄進行部署,例如 Azure Container Registry。 使用登錄的訪問控制機制,確保只有受信任的叢集提取可能包含敏感性資訊的容器。 Azure Container Registry 同時支援 角色型訪問控制 (RBAC) 和 屬性型訪問控制 (ABAC) ,以進一步限定特定存放庫的範圍指派。
此外,透過 Azure 原則強制執行容器安全性衛生的最佳做法標準。 例如,您可以使用 Azure 原則的內建定義,驗證所有 Pod 都符合低程式碼方法中的 Pod 安全性標準。 您也可以將擴充 Gatekeeper 的 Azure 原則延伸模組部署到邊緣 Kubernetes 叢集,以大規模套用 Pod 型安全性強制執行。 建議您先在「稽核」模式中套用政策指派。 此模式會針對每個 Kubernetes 資源、每個原則粒度提供不符合規範結果的匯總清單,讓您先找出並補救執行中部署的任何現有問題。 修正環境中不符合規範的違規之後,您就可以將原則指派更新為「拒絕」模式。 Azure 原則的豐富安全部署機制接著會逐步跨資源推出此原則強制執行。 藉由在強制模式中套用原則,您可以主動防止任何進一步的偏差。
參考資料
偵測新興威脅,包括監視控制平面的變更
協助確保您能在叢集中威脅出現時即時偵測它們。
您可以將 適用於容器的 Defender 擴充功能 部署至邊緣的 Kubernetes 叢集。 此擴充功能包括一個感測器,此感測器會收集記錄並將它們傳送到 Defender for Cloud。 到達那裡後,可以分析異常行為以判斷是否有攻擊跡象,或在可能的事件發生後用於鑑識。 請參閱 支援矩陣,以了解哪些功能在預覽或 GA 版本中支援,以及它們適用於哪些叢集類型。 接著,適用於雲端的 Defender 可以傳送事件進行分析,作為 Microsoft Defender XDR 事件偵測和回應解決方案的一部分。
如果您在 Azure Local 上的 Azure Arc 所啟用的 AKS 上執行,您也可以 將其設定為將 Kubernetes 稽核記錄傳送至 Azure 監視器 (Log Analytics 工作區)。 同時請請遵循有關監視您工作負載本身的相關建議。 並查看監視叢集的 最佳做法 ,其中涵蓋可靠性、成本優化、效能和安全性。
除了監控之外,還應著手建立事件回應計劃,並實際使用它來進行練習。 這類計劃的詳細數據在很大程度上取決於您的整體部署環境,以及您使用的安全性作業工具:如需詳細資訊,請參閱本指南。 但至少,請考慮如何保留叢集的狀態(保留稽核記錄、快照可疑狀態),以及如何將 它復原到已知良好的狀態。
參考資料
- CIS Kubernetes 基準測試 - 第 3.2 節
- NIST 應用程式容器安全性指南 - 第 4.4.4 節
- NSA Kubernetes 強化指引 –「威脅偵測」
- Kubernetes 安全性 - OWASP 速查表系列:「記錄」 (英文)
使用部署策略來達成零停機更新
重大安全更新即使緊急推出,也不應影響工作負載的可靠性與可用性。 選擇最能協助維護環境中高可用性的 Kubernetes 部署策略 。 也請考慮實作整備度和活躍度探查 (英文),使 Kubernetes 在維護部署時能更好地掌握工作負載的狀態。 結合輸入負載平衡器的漸進式推出和流量管理原則,您可以使用 Kubernetes 來驅動更新,而不會中斷應用程式的可用性。