K8s云服务器集群安全实战：网络策略与RBAC配置

K8s云服务器集群凭借强大的容器编排能力，已成为企业构建弹性架构的核心选择。但随着业务规模扩大，集群面临的安全威胁也日益复杂——曾有企业因未配置网络策略，攻击者通过开放端口渗透至数据库；也有团队因RBAC权限过度下放，导致恶意账户删除关键服务。这些真实案例提醒我们：K8s云服务器集群的安全，需从网络流量管控与权限精细化分配双管齐下。

网络策略：构建集群流量"防火墙"

在K8s云服务器集群中，容器间的通信默认是无限制的。这意味着若某个容器被攻破，攻击者可能顺着网络链路渗透至整个集群。网络策略（NetworkPolicy）的作用，就是为集群内的流量设置"交通规则"，只允许符合条件的通信通过。

举个实际场景：某电商系统的前端服务（标签app: frontend）需要调用后端API（标签app: backend），但财务系统（标签app: finance）禁止与前端直接通信。此时可通过网络策略限制frontend到backend的8080端口访问，同时阻断frontend对finance的所有流量。若未配置此类策略，攻击者侵入前端容器后，可能直接扫描到finance服务的数据库端口，进而窃取订单数据。

配置网络策略时需注意两点：一是优先启用默认拒绝策略（Default Deny），即未明确允许的流量全部阻断；二是结合标签（Label）精准定位目标Pod。以下是一个限制特定IP段访问的示例：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-frontend-access
spec:
  podSelector:
    matchLabels:
      app: backend  # 目标后端服务Pod
  policyTypes:
  - Ingress  # 仅控制入站流量
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend  # 允许前端Pod访问
    ports:
    - protocol: TCP
      port: 8080  # 仅开放8080端口

这个策略表示：仅允许标签为app: frontend的Pod，通过TCP 8080端口访问标签为app: backend的Pod，其他入站流量均被阻断。实际部署后，可通过`kubectl get networkpolicy`查看生效情况，并用`kubectl run`启动测试Pod验证策略是否生效。

RBAC权限：最小化原则下的精准管控

RBAC（基于角色的访问控制）是K8s云服务器集群权限管理的核心机制。其核心逻辑是：先定义角色（Role）赋予具体权限（如查看Pod、删除Service），再通过角色绑定（RoleBinding）将角色分配给用户或服务账户（ServiceAccount）。

曾遇到某团队运维人员误操作：因普通用户被授予cluster-admin权限，一次误删命令导致3个命名空间的服务全部下线。这正是典型的权限过度分配问题。遵循"最小权限原则"，应确保每个用户/账户仅拥有完成任务所需的最低权限。

以日志审计场景为例：审计人员需要查看所有Pod的日志，但不能修改或删除资源。此时可创建一个仅包含pods/get和pods/logs权限的角色，并绑定给审计用户。具体YAML配置如下：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: log-auditor
  namespace: production  # 限定在production命名空间
rules:
- apiGroups: [""]  # 核心API组
  resources: ["pods"]
  verbs: ["get", "list", "logs"]  # 仅允许查看和获取日志
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: auditor-binding
  namespace: production
subjects:
- kind: User
  name: auditor@example.com  # 审计用户邮箱
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: log-auditor
  apiGroup: rbac.authorization.k8s.io

此配置下，审计用户只能查看production命名空间内Pod的基本信息和日志，无法执行删除或修改操作，有效降低了误操作风险。

实战优化：从静态配置到动态防护

完成基础配置后，还需持续优化安全策略。建议定期通过`kubectl describe networkpolicy`检查网络策略覆盖范围，避免遗漏关键服务；对于RBAC权限，可使用`kubectl auth can-i`命令验证用户权限是否符合预期。

另外，结合K8s的准入控制器（Admission Controller）可实现动态防护。例如，部署Pod时强制检查是否绑定了网络策略，未绑定则拒绝创建；或通过自定义Webhook，对RBAC角色的权限范围进行二次校验，防止出现"超级角色"。

K8s云服务器集群的安全是动态过程，需根据业务变化调整网络策略粒度，根据人员职责更新RBAC权限。只有将"流量可控"与"权限可溯"结合，才能构建真正可靠的容器化安全体系。