在 Kubernetes 的世界里，安全 是构建可靠集群的关键能力之一。很多开发者往往将安全防护的重点放在权限管理层面，却忽略了网络层的流量控制；或反之，只关注网络隔离而忽略了 API 调用的授权治理。实际上，NetworkPolicy 与 RBAC 是 Kubernetes 中互为补充的两道安全防线：前者守护 Pod 之间的网络通信，后者管控用户/服务账户对资源的访问能力。
本文将深入讲解这两者的设计原理、应用场景、实际使用策略，并通过对比分析帮助你构建更完善的安全控制体系。
一、NetworkPolicy：基于标签的网络流量控制器
Kubernetes 默认允许所有 Pod 与所有 Pod 通信，这是最开放的配置，也是最危险的配置。NetworkPolicy 就是用来精细控制"谁可以跟谁通信"的机制。
1. NetworkPolicy 的核心能力
NetworkPolicy 是作用在 Pod 上的资源对象，用来控制：
- Pod 的 入站（Ingress） 与 出站（Egress） 流量
- 基于 标签选择器 和 命名空间选择器 设定通信规则
- 可支持 IP Block、Port、Protocol 等多维规则
它的核心语义是 "白名单策略" ------ 一旦某个 Pod 被 NetworkPolicy 命中，未被显式允许的流量就会被拒绝。
2. 示例：仅允许 frontend Pod 访问 backend 服务
yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend-to-backend
namespace: default
spec:
podSelector:
matchLabels:
app: backend
ingress:
- from:
- podSelector:
matchLabels:
role: frontend该策略表示：只有带有 role=frontend 标签的 Pod 才能访问 app=backend 的 Pod。
3. NetworkPolicy 的支持条件
注意，并非所有网络插件都支持 NetworkPolicy。如 Flannel 的默认配置并不支持，而 Calico、Cilium 等则具备完善支持。
二、RBAC：Kubernetes 的资源访问授权机制
如果说 NetworkPolicy 控制的是 Pod 与 Pod 之间的"通话权限"，那么 RBAC（基于角色的访问控制） 则是管理用户/服务账户能否"打电话"的机制，即是否允许访问集群 API 资源。
1. RBAC 的基本概念
RBAC 涉及四个核心资源：
- Role / ClusterRole：定义权限
- RoleBinding / ClusterRoleBinding：将权限绑定给用户或服务账户
其中：
Role与RoleBinding限于某个命名空间ClusterRole与ClusterRoleBinding是集群范围的
2. 示例：只允许 dev-sa 服务账户读取 default 命名空间下的 Pod
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: read-pods
namespace: default
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods-binding
namespace: default
subjects:
- kind: ServiceAccount
name: dev-sa
namespace: default
roleRef:
kind: Role
name: read-pods
apiGroup: rbac.authorization.k8s.io三、NetworkPolicy vs RBAC：场景对比与协同使用
| 对比维度 | NetworkPolicy | RBAC |
|---|---|---|
| 控制对象 | Pod 网络通信 | 用户/服务账户的 API 调用权限 |
| 应用维度 | 数据平面（Data Plane） | 控制平面（Control Plane） |
| 主要用途 | 网络隔离、东西向流量控制 | 管理 API 访问权限、资源操作授权 |
| 示例 | 允许 A 访问 B 的网络流量 | 允许某用户对某资源执行 GET 操作 |
| 应用典型插件支持 | 需配合支持的 CNI，如 Calico、Cilium | 原生支持，无需插件 |
协同举例：构建服务安全闭环
设想某微服务 A 需要调用服务 B 的 API，且只允许在某命名空间中通信。
- 使用 NetworkPolicy 控制只有 A 的 Pod 可以访问 B 的 Pod 网络端口
- 使用 RBAC 限制 A 使用的 ServiceAccount 只能访问 B 所在资源的 API 操作权限
这样就实现了：流量上封口、权限上设限，控制面与数据面双层防护。
四、实战建议与常见误区
1. 不使用默认宽松策略
不要依赖 Kubernetes 默认的"全部可通"的网络策略，部署应用时就应配套定义 NetworkPolicy。
2. ServiceAccount 与 RBAC 绑定必不可少
很多人配置了 Pod 网络策略，却忽略服务账户权限，导致 Pod 可以调用集群 API 资源甚至越权操作。
3. 动态调整与可视化
使用工具（如 Kubeaudit、Kyverno、Cilium UI）定期检查现有策略是否过于宽松或存在冲突。
五、总结
在构建 Kubernetes 安全体系时，NetworkPolicy 与 RBAC 是从两个维度协同构建安全边界的关键工具。理解它们的边界与交集，合理配置策略，是保障集群安全的基础。
- NetworkPolicy：定义"谁能访问谁"的网络通路
- RBAC：定义"谁能做什么"的资源操作权限
建议从服务粒度出发，结合 Zero Trust 的理念，将最小权限原则贯彻到底，形成安全闭环。