解读Kubernetes安全审计中的IAM与网络策略关键配置

Kubernetes安全审计，很多时候被简化成了漏洞扫描和版本检查。但真正让安全工程师夜里惊醒的，往往是那些隐藏在优雅YAML文件里的配置“地雷”——尤其是身份访问管理（IAM）和网络策略。这两者一旦配置失当，攻击者就能在集群内部如入无人之境。

IAM配置：权限的“最小特权”不是口号

谈起IAM，很多团队的第一反应是绑定一个现成的cluster-admin ClusterRole，图个方便。这相当于把整个数据中心的管理员钥匙交给了每一个微服务。审计时，你需要像侦探一样审视每一个ServiceAccount、Role和RoleBinding。

一个经典的陷阱是通配符（*）资源的使用。比如，一个用于日志收集的ServiceAccount，其绑定的Role如果被配置为对pods资源拥有get, list, watch权限，这看起来合理。但如果这个Role是通过RoleBinding绑定到了整个命名空间，而非特定的ServiceAccount，或者权限定义中不慎包含了pods/exec或pods/portforward，情况就截然不同了。攻击者一旦劫持了该身份，就获得了在任意Pod内执行命令的能力。

审计的关键在于关联性分析。不能只看单独的Role定义，必须结合RoleBinding和ClusterRoleBinding，理清“谁（Subject）通过什么绑定（Binding）拥有了哪些权限（Rules）”。自动化工具能列出所有过宽的权限，但判断其合理性仍需人工介入：这个前端应用真的需要secrets的list权限吗？

网络策略：默认放行的“隐形大门”

如果说IAM是内部门禁卡，那么网络策略就是控制微服务间流量的内部防火墙。Kubernetes的默认行为是：如果命名空间内没有NetworkPolicy，则所有Pod之间可以自由通信。这个“默认放行”原则，是大多数横向移动攻击的根源。

审计网络策略，首先要回答一个基础问题：策略是否存在？ 许多集群在非核心命名空间（如default）中完全缺失NetworkPolicy。其次，要检查策略的“默认拒绝”规则是否到位。一个健壮的策略应该像这样开头：

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

这条策略会拒绝所有进出流量，然后再用其他策略按需“开口子”。审计时需要验证这些“口子”是否开得过宽。例如，一条允许从app=frontend的Pod到app=backend的Pod的TCP 8080端口的策略是精确的。但如果策略中的podSelector为空（匹配所有Pod），或者端口范围被定义为1-65535，这就构成了严重的过度许可。

IAM与网络策略的联动盲区

最危险的场景，是IAM的越权与网络策略的宽松产生化学反应。想象一下：一个拥有过宽权限的ServiceAccount（比如能列出所有Secrets）被运行在一个没有任何网络策略限制的Pod中。攻击者如果通过应用漏洞入侵该Pod，不仅能窃取敏感数据，还能以该Pod为跳板，不受限制地扫描和攻击集群内网的其他服务。

因此，高级别的安全审计必须进行跨维度检查。例如，检查那些绑定了高权限Role的ServiceAccount，其对应的Pod是否运行在具有严格网络策略隔离的命名空间中。如果没有，这就是一个需要优先修复的高风险项。

说到底，Kubernetes的安全配置审计不是运行一遍扫描工具就完事了。它要求审计者深刻理解集群的架构意图，像攻击者一样思考，在复杂的权限与网络规则矩阵中，找出那条本不该存在的、连通了核心资产的小径。每一次审计，本质上都是在挑战“便利性”与“安全性”之间的那道微妙边界。