安全壁垒 - 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