安全壁壘 - K8s 的 RBAC、NetworkPolicy 與 SecurityContext 精要

---

如果說 Kubernetes 是我們構建云原生應用的“城市”，那么我們已經學會了如何規劃道路（網絡）、建設住宅（Pod 調度）、提供水電（存儲）以及智能調節城市規模（自動伸縮）。現在，是時候為這座城市安裝“城門門禁”（API 訪問控制）、劃分“安全區域”（網絡隔離）、加固“建筑安防”（運行時安全）以及設置“保險柜”（敏感信息管理）了。

K8s API 訪問控制：RBAC (基于角色的訪問控制)

Kubernetes 的所有操作都是通過與其 API Server 組件交互來完成的。因此，保護 API Server 并精確控制誰（Subject）可以對哪些資源（Resource）執行哪些操作（Verb） 是 K8s 安全的第一道防線。這就是 RBAC (Role-Based Access Control) 的用武之地。

• 核心概念:

  1. Subject (主體)：發起請求的“人”或“程序”。可以是：
     • User: 代表真實的人類用戶。
     • Group: 代表一組用戶。
     • ServiceAccount: 代表運行在 Pod 內的進程身份，供應用程序或 K8s 內部組件與 API Server 交互。
  2. Resource (資源)：API Server 中可以被操作的對象，如 pods, deployments, services, nodes, secrets, configmaps 等。
  3. Verb (動詞)：可以對資源執行的操作，如 get, list, watch, create, update, patch, delete, exec 等。
  4. Role / ClusterRole (角色 / 集群角色)：一組權限規則的集合，定義了允許對哪些資源執行哪些動詞。
     • Role: 命名空間級別的，其權限僅在定義的 Namespace 內有效。
     • ClusterRole: 集群級別的，其權限在整個集群內都有效（也可以用于授權訪問非命名空間資源，如 nodes）。
  5. RoleBinding / ClusterRoleBinding (角色綁定 / 集群角色綁定)：將一個主體（User, Group 或 ServiceAccount）與一個角色（Role 或 ClusterRole）綁定起來，從而將角色中定義的權限授予該主體。
     • RoleBinding: 在特定命名空間內進行綁定。
     • ClusterRoleBinding: 在整個集群范圍內進行綁定。

• SRE 的最佳實踐:

  • 最小權限原則 (Principle of Least Privilege)：永遠只授予必要的最小權限。避免隨意給用戶或 ServiceAccount 授予 cluster-admin 這種超級權限。
  • 為應用使用 ServiceAccount: 應用 Pod 如果需要訪問 API Server（例如，某些監控組件或 Operator），應該為其創建專用的 ServiceAccount，并精確綁定所需的 Role 或 ClusterRole。不要使用默認的 ServiceAccount 或共享高權限賬戶。
  • 定期審計 RBAC 配置: 檢查是否有過多或不必要的權限分配。

• 配置示例:
  假設我們要創建一個 pod-reader Role，允許讀取 my-ns 命名空間下的 Pod 信息，并將其綁定到一個名為 app-reader-sa 的 ServiceAccount。

  # role-pod-reader.yaml
  apiVersion: rbac.authorization.k8s.io/v1
  kind: Role
  metadata:namespace