應用程式安全檢查清單

此檢查清單旨在從開發人員的角度提供保護在 Kubernetes 中執行的應用程式的基本指南。此列表並非詳盡無遺，並且旨在隨著時間的推移而發展。

關於如何閱讀和使用本文檔

• 主題的順序不反映優先順序。
• 一些檢查清單項目在每個章節列表下方的段落中詳細說明。
• 此檢查清單假設 開發人員 是與命名空間範圍物件互動的 Kubernetes 叢集使用者。

基本安全強化

以下檢查清單提供適用於部署到 Kubernetes 的大多數應用程式的基本安全強化建議。

應用程式設計

• 在設計應用程式時，請遵循正確的 安全原則。
• 應用程式配置了適當的 QoS 類別，透過資源請求和限制。
  • 為工作負載設定記憶體限制，其限制等於或大於請求。
  • 可能會在敏感工作負載上設定 CPU 限制。

服務帳戶

• 避免使用 預設 服務帳戶。相反地，為每個工作負載或微服務建立服務帳戶。
• 除非 Pod 特別需要存取 Kubernetes API 才能運作，否則 automountServiceAccountToken 應設定為 false。

Pod 層級 securityContext 建議

• 設定 runAsNonRoot: true。
• 將容器配置為以較低權限的使用者執行 (例如，使用 runAsUser 和 runAsGroup)，並在容器映像檔內的文件或目錄上配置適當的權限。
• 選擇性地使用 fsGroup 新增補充群組以存取持久磁碟區。
• 應用程式部署到強制執行適當 Pod 安全標準 的命名空間中。如果您無法控制應用程式部署到的叢集的此強制執行，請透過文件或額外的深度防禦來考量這一點。

容器層級 securityContext 建議

• 停用特權提升，使用 allowPrivilegeEscalation: false。
• 將根檔案系統配置為唯讀，使用 readOnlyRootFilesystem: true。
• 避免以特權模式執行容器（設定 privileged: false）。
• 從容器中移除所有 capabilities，僅加回容器運作所需的特定 capabilities。

基於角色的存取控制（RBAC）

• 諸如 create、patch、update 和 delete 等權限，應僅在必要時授予。
• 避免建立 RBAC 權限來建立或更新角色，這可能會導致特權提升。
• 檢閱 system:unauthenticated 群組的繫結，並盡可能移除它們，因為這會讓任何可以從網路層級連線到 API 伺服器的人員取得存取權。

應謹慎授與 create、update 和 delete 動詞。若允許在命名空間上使用 patch 動詞，可能會允許使用者更新命名空間或部署上的標籤，進而增加攻擊面。

對於敏感工作負載，請考慮提供建議的 ValidatingAdmissionPolicy，以進一步限制允許的寫入操作。

映像檔安全性

• 在 Kubernetes 叢集中部署容器之前，使用映像檔掃描工具掃描映像檔。
• 使用容器簽章來驗證容器映像檔簽章，然後再部署到 Kubernetes 叢集。

網路原則

• 配置 NetworkPolicies，僅允許來自 Pod 的預期輸入和輸出流量。

確保您的叢集提供並強制執行 NetworkPolicy。如果您正在編寫將由使用者部署到不同叢集的應用程式，請考慮是否可以假設 NetworkPolicy 可用且已強制執行。

進階安全性強化

本指南的此章節涵蓋一些進階安全性強化重點，這些重點可能根據不同的 Kubernetes 環境設定而有價值。

Linux 容器安全性

為 Pod 容器配置Security Context。

• 為容器設定 Seccomp Profile.
• 使用 AppArmor 限制容器對資源的存取.
• 為容器指派 SELinux 標籤.

執行期類別

• 為容器配置適當的執行期類別。

某些容器可能需要與叢集預設執行期所提供的隔離層級不同的隔離層級。runtimeClassName 可在 PodSpec 中用於定義不同的執行期類別。

對於敏感工作負載，請考慮使用核心模擬工具（如 gVisor）或使用虛擬化隔離機制（如 kata-containers）。

在高信任環境中，請考慮使用機密虛擬機器，以進一步提高叢集安全性。