企业官网建设流程全解析

上一篇【第55篇】SecurityContext——容器安全配置的"三件套"
下一篇【第57篇】Secret管理的最佳实践——Vault/SealedSecrets/External Secrets

摘要

第047篇我们讲了NetworkPolicy的语法，第047篇也提了"默认拒绝"的思路。但语法≠架构。真要在生产环境搭一套安全的网络，你需要的是从安全原则出发的整体设计，而不是零散的几条规则。

这就是零信任（Zero Trust）网络——它的核心信条是"永不信任，始终验证"。在K8s里翻译成大白话：默认所有Pod之间都不通，然后一条条精确放通"必须通"的链路。

这篇文章从零信任三原则讲起，给你一套三层应用的完整微隔离方案（前端→后端→数据库），再讲namespace之间的流量控制，最后看看Cilium怎么把策略做到HTTP级别。读完你就能照着给自己的集群"上锁"。

一、零信任的三条铁律

1.1 原则

【零信任网络的三条铁律】 铁律1: 默认拒绝一切 (Default Deny) • 没有任何策略时 = 全通(危险!) • 安全做法: 先锁死，再发钥匙 铁律2: 最小权限 (Least Privilege) • 只放通"业务必须的"那条链路 • frontend→backend:8080 放行 • frontend→database:5432 绝不放行(越级访问!) 铁律3: 假设已被突破 (Assume Breach) • 即使一个Pod被攻陷，它的"活动范围"已被策略锁死 • 攻击者横向移动的成本被极大抬高

要点：零信任的精髓是心态转变——从"内部是可信的"变成"内部也不可信"。传统网络像公司大楼，进了大门就能到处走；零信任像银行金库，每个房间都要单独授权。在K8s里，NetworkPolicy就是你实现这种"金库模型"的工具。

二、三层应用微隔离实战

2.1 架构目标

【我们要实现的安全拓扑】 Internet │ (只放Ingress Controller进frontend) ▼ [Ingress Nginx] ──allow 80/443──► [frontend] │ (只放frontend→backend:8080) ▼ [backend] │ (只放backend→database:5432) ▼ [database] │ └─ allow DNS (否则全崩) 禁止的访问(策略自动挡)： • frontend → database (越级!) • Internet → backend (绕过前端!) • frontend → 其他namespace (乱窜!)

2.2 完整策略集

# ① 基础锁：默认拒绝所有入站+出站(必须先有这条)apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:default-denynamespace:shopspec:podSelector:{}policyTypes:[Ingress,Egress]# ② 放行DNS(否则Pod连名字都解析不了，应用直接崩)apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:allow-dnsnamespace:shopspec:podSelector:{}policyTypes:[Egress]egress:-to:-namespaceSelector:{}ports:-{protocol:UDP,port:53}-{protocol:TCP,port:53}# ③ Ingress Controller → frontendapiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:frontend-from-ingressnamespace:shopspec:podSelector:matchLabels:{app:frontend}policyTypes:[Ingress]ingress:-from:-namespaceSelector:matchLabels:{kubernetes.io/metadata.name:ingress-nginx}ports:-{protocol:TCP,port:80}# ④ frontend → backend:8080apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:backend-from-frontendnamespace:shopspec:podSelector:matchLabels:{app:backend}policyTypes:[Ingress]ingress:-from:-podSelector:matchLabels:{app:frontend}ports:-{protocol:TCP,port:8080}# ⑤ backend → database:5432apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:db-from-backendnamespace:shopspec:podSelector:matchLabels:{app:database}policyTypes:[Ingress]ingress:-from:-podSelector:matchLabels:{app:backend}ports:-{protocol:TCP,port:5432}

要点：这套策略的关键在顺序——先default-deny锁死，再DNS放行（否则应用崩），然后逐层放通链路。注意第⑤条database的策略只接受来自backend的流量，frontend根本不在白名单里，所以"frontend直连database"会被自动挡掉，实现了严格的层级隔离。

三、namespace之间的流量控制

3.1 多团队隔离

【跨namespace的流量控制——"部门墙"】 namespace: team-a (前端团队) namespace: team-b (数据团队) team-a 的Pod 默认不能访问 team-b 的Pod → 除非显式写策略允许 典型需求：team-a 的 backend 需要访问 team-b 的 mysql → 在 team-b 里写一条策略，from 指定 team-a 的namespace

# team-b (数据团队) 里允许 team-a 的backend访问mysqlapiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:mysql-allow-teama-backendnamespace:team-bspec:podSelector:matchLabels:{app:mysql}policyTypes:[Ingress]ingress:-from:-namespaceSelector:matchLabels:{team:team-a}podSelector:matchLabels:{app:backend}ports:-{protocol:TCP,port:3306}

四、Cilium把策略做到L7

4.1 HTTP级别隔离

传统NetworkPolicy只能到L4（端口）。Cilium的CiliumNetworkPolicy能到L7：

# 只允许 frontend 对 backend 发 GET /api，拒绝一切其他请求apiVersion:cilium.io/v2kind:CiliumNetworkPolicymetadata:name:backend-l7spec:endpointSelector:matchLabels:{app:backend}ingress:-fromEndpoints:-matchLabels:{app:frontend}toPorts:-ports:-port:"8080"protocol:TCPrules:http:-method:"GET"path:"/api/.*"

【L4 vs L7 策略——"能进门" vs "能碰保险柜"】 L4 (NetworkPolicy): "允许 frontend → backend:8080" → 黑客可以 POST /admin/delete，照样进！ L7 (CiliumNetworkPolicy): "允许 frontend → backend:8080 的 GET /api/*" → POST /admin/delete 被直接拦在L7

要点：L7策略是微服务安全的"终极形态"——它理解应用协议，能在方法/路径/Header级别做访问控制。但只有Cilium等支持eBPF的插件能做到（见第049篇）。对绝大多数场景，L4的NetworkPolicy已经能提供扎实的微隔离；对金融、多租户等高安全场景，上Cilium做L7。

五、验证你的零信任网络

# 1. 故意从frontend直连database(应该失败)kubectlexec-itfrontend-xxx-nshop --\nc-zvdatabase5432# ❌ 超时/拒绝 → 策略生效！# 2. 从backend连database(应该成功)kubectlexec-itbackend-xxx-nshop --\nc-zvdatabase5432# ✅ 连接成功 → 链路放通正确# 3. 看Calico/Cilium的策略是否真的落地kubectlexec-nkube-system calico-node-xxx --\calicoctl get networkpolicy-owide

本篇小结

零信任网络三铁律：默认拒绝、最小权限、假设已被突破。在K8s里落地就是"先default-deny锁死所有流量，再放行DNS，然后逐层精确放通业务链路"。三层应用（前端→后端→数据库）的隔离实战是最常见的模板，关键是database的策略只接受backend，越级访问自动被挡。

跨namespace用namespaceSelector做"部门墙"。需要HTTP/gRPC级别隔离（金融/多租户），上Cilium的L7策略。下一篇聊Secret管理——K8s里敏感信息的"保险箱"该怎么用才安全。

上一篇【第55篇】SecurityContext——容器安全配置的"三件套"
下一篇【第57篇】Secret管理的最佳实践——Vault/SealedSecrets/External Secrets