核心是构建多层、可验证、动态生效的通信控制体系，默认拒绝所有流量并按业务角色精准放行，严格限制出向连接，叠加底层网络与运行时加固形成纵深防御。
要防止黑客利用容器环境在内网横向渗透，核心不是“堵住所有漏洞”，而是构建多层、可验证、动态生效的通信控制体系。关键在于让攻击者即使突破一个容器，也无法发现、连接或利用其他服务。
默认拒绝所有流量，从零建立信任
这是最基础也最关键的一步。Kubernetes 默认允许所有 Pod 互通，必须主动打破这个隐含信任。
- 立即部署一个集群级默认拒绝策略，覆盖所有命名空间：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: default
spec:
podSelector: {}
policyTypes: [Ingress, Egress]
- 该策略不依赖任何标签，作用于所有 Pod；它本身不放行任何流量，后续策略需显式声明允许项；
- 建议先在非生产命名空间验证，确认业务无异常后再推广至 prod；
- 若使用 Cilium 或 Calico，还可配合其全局默认策略（如 CiliumClusterwideNetworkPolicy）实现跨命名空间统一基线。
按业务角色精准放行，而非按IP或端口
横向渗透常依赖扫描和试探。用标签（label）定义角色，比写死 IP 段或开放 22/3389 等通用端口更安全、更可持续。
- 为 Pod 打上语义化标签，例如 tier: frontend、app: payment-db、sensitive: true；
- 只允许前端访问后端 API 的特定端口，且仅限指定标签的 Pod：
ingress:
- from:
- podSelector:
matchLabels:
tier: frontend
ports:
- protocol: TCP
port: 8080
- 数据库类敏感 Pod 应禁止任何来自 default 命名空间的入向连接，只接受带 app: order-service 标签的 Pod 访问；
- 避免使用 namespaceSelector 允许整个命名空间——这等于把“测试环境”也纳入信任范围，违背最小权限原则。
严格限制出向连接，切断横向移动链路
黑客攻陷容器后，第一件事往往是探测内网：扫描 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 等常见私有网段。阻断这类出向行为，能直接卡住横向渗透第一步。
- 对高风险 Pod（如面向公网的 API 网关、边缘容器），单独配置 egress 策略：
egress:
- to:
- ipBlock:
cidr: 10.10.0.0/16
except:
- 10.10.5.10/32 # 仅允许连 DB VIP
- to:
- namespaceSelector:
matchLabels:
network-policy: allowed-egress
- 注意：Kubernetes v1.23+ 原生支持 egress；低于此版本需依赖 CNI 插件（如 Cilium）或宿主机 iptables 补充；
- 对于 legacy 环境，可在宿主机 DOCKER-USER 链中添加硬性拦截规则，例如：
iptables -I DOCKER-USER -s 172.18.0.0/16 -d 172.16.100.0/24 -j DROP； - 该规则不会被 Docker daemon 覆盖，适合做兜底防护。
结合底层网络与运行时加固，补全盲区
NetworkPolicy 是声明式策略，但无法覆盖所有场景。需叠加宿主机层和运行时层控制，形成纵深防御。
- 禁用不安全网络模式：严禁在生产环境使用 host 模式容器——它绕过所有 NetworkPolicy，共享宿主机网络栈；
- 对无需外联的后台任务容器（如离线批处理），使用 none 网络模式，彻底断开网络；
- 启用 CNI 插件的 eBPF 流量可见性（如 Cilium 的 Hubble），实时观测哪些 Pod 在尝试连接敏感网段，及时发现异常行为；
- 配合蜜罐思路，在内网敏感网段旁部署低交互蜜罐容器（如监听 3306/1433 的假数据库），一旦被探测即触发告警并联动封禁源 Pod IP。
