这是一个值得关注的 Kubernetes 安全问题。简单来说：

RBAC：控制“谁能”在集群内“做什么”，例如：创建 Pod、删除 Service；NetworkPolicy：控制“哪个 Pod”能“访问”另一个 Pod 的“哪个端口”，例如：前端 Pod 只能访问后端 Pod 的 8080 端口。

它们一个管“账号权限”，一个管“网络流量”，共同构成了 Kubernetes 的安全体系。

一起来看看他们具体的工作方式。

1. RBAC：控制“谁能做什么”

RBAC 的工作模式是“绑定授权”，通过四个关键资源实现：

（1）Role / ClusterRole：定义了一组操作规则。ClusterRole 是集群级别的，可以跨命名空间使用。

（2）Subject：操作的发起方，可以是用户、服务账号 (ServiceAccount) 或组。

（3）RoleBinding / ClusterRoleBinding：把“规则”和“用户”绑定在一起。2. NetworkPolicy：控制“哪个 Pod 能访问哪个 Pod”。

 现在我们来编辑一个yaml文件，让 my-sa 这个服务账号只能 get 和 list Pod 信息，不能删除。代码如下：

当 my-sa 尝试 kubectl delete pod 时，API Server 会检查 RBAC 规则，发现 pod-reader 规则里没有 delete 权限，就会直接拒绝这次操作。

2. NetworkPolicy：控制“哪个 Pod 能访问哪个 Pod”

NetworkPolicy 的工作模式是“白名单规则”，通过定义三个维度来控制流量：

（1）podSelector：规则作用于哪些 Pod。

（2）policyTypes：控制入站 (Ingress) 还是出站 (Egress) 流量。

（3）规则内容：允许哪类来源的 Pod（通过 namespaceSelector 或 podSelector 指定）访问本 Pod 的哪个端口。

现在我们来编辑一个yaml文件，限制 backend 命名空间中的 Pod 只能被 frontend 命名空间中的 Pod 访问，且只能访问 8080 端口。

当 frontend 命名空间的一个 Pod 访问 backend 命名空间某个 Pod 的 8080 端口时，NetworkPolicy 会放行流量。但如果用 curl http：//backend-pod：22 访问 SSH 端口，或者从 database 命名空间发起访问，网络插件就会直接拒绝或丢弃这些数据包。

4. 实际配合场景

通常需要两者配合才能实现完整的安全隔离。例如，我们现在要求：只允许 监控服务 的 ServiceAccount 访问 metrics Pod。

那么，RBAC 的工作是：防止用户用 kubectl exec 登入 Pod。只有 监控服务 的 ServiceAccount 才有权限访问 metrics 这个 API 资源。

NetworkPolicy 负责在底层阻断网络。即使有人盗用了 监控服务 的账号，试图从另一个 Pod 发起网络请求，NetworkPolicy 也会在 TCP/IP 层面拦截该网络包。

5.总结

RBAC防护的是 API Server，是对“操作”本身的许可。可以理解为用户登录系统后的操作权限。

NetworkPolicy防护的是 Pod 网络，是对“流量”的隔离。可以理解为不同服务器之间的防火墙规则。

它们处理的是不同层面的安全问题，没有重叠，也不能相互替代。