防御容器集群内部横向攻击的关键是实施NetworkPolicy默认拒绝策略：即绑定命名空间、设置policyTypes为[Ingress, Egress]、podSelector:{}且ingress/egress为空数组，从而阻断所有Pod间未明确授权的入站和出站流量。
防御容器集群内部横向攻击，关键在于切断攻击者在Pod之间自由移动的路径。默认开放的“东西向”网络是最大隐患，必须用细粒度、可动态更新的网络策略主动收敛通信面。
默认拒绝所有流量
这是最基础也最关键的一步。Kubernetes原生NetworkPolicy支持“默认拒绝”模型，即不显式放行就一律阻断。启用后，所有Pod间入站和出站流量都会被拦截，除非你明确声明允许规则。
- 策略需绑定到命名空间，避免全局误配
- 务必同时设置
policyTypes: [Ingress, Egress]，否则仅控制入向，出向仍畅通 - 建议在集群初始化阶段就部署该策略，防止新Pod上线即暴露
按最小权限原则定义通信规则
每条允许规则都应精确到标签选择器、端口、协议和方向。例如：前端Pod只允许访问后端Service的8080端口，且仅限TCP；数据库Pod禁止接收任何来自非中间件Pod的连接。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 用
podSelector匹配源或目标Pod，避免使用宽泛的matchLabels: {} - 优先使用
ipBlock限制外部CIDR，而非依赖不可靠的Pod IP - 对敏感服务（如etcd、metrics）单独设策略，禁止非管理组件访问
用eBPF增强策略执行能力
原生NetworkPolicy依赖kube-proxy或iptables，存在延迟高、状态跟踪弱等问题。Cilium等基于eBPF的方案可在内核层实时拦截并审计流量，支持L7协议识别（如HTTP路径、gRPC方法），还能自动适配Pod IP变更。
- eBPF程序挂载在veth对的TC入口，不依赖用户态代理，性能损耗更低
- 支持服务身份标识（如SPIFFE ID）替代IP+端口，应对弹性扩缩场景
- 配合可观测性工具，可生成服务调用拓扑图，快速定位异常通信链路
结合运行时行为持续校验策略有效性
静态策略可能滞后于实际业务变化。需引入运行时防护机制，比如检测未授权的DNS查询、异常端口扫描、高频失败连接等行为，自动触发告警或临时阻断。
- 启用Cilium或Falco的运行时策略引擎，对违反预期通信模式的行为实时响应
- 定期用
kubectl get networkpolicies -A审计策略覆盖范围，确认无遗漏命名空间 - 将策略配置纳入CI/CD流水线，与应用部署同步验证，避免“策略漂移”
