一个工程师把K8s藏进内网，然后事情变复杂了

导读：把Kubernetes控制面从公网撤下来，是安全团队的经典操作。但代价是：每次kubectl都要先连VPN、跳堡垒机、配路由表——这位工程师把整套流程自动化了，还顺手塞了个"政策警察"进去。

一、先画张图：这套架构长什么样

想象一个三层同心圆。

最外层是公网，只有一个入口：一台跑着OpenVPN的堡垒机。中间层是三个私有子网，EKS的节点泡在里面。最核心的是控制平面——API服务器——彻底隐身，连AWS控制台都找不到它。

这位工程师用Terraform把这四层全串起来：/16的VPC切出三个/24私有子网，留一个公共子网给入口。堡垒机模块自动生成客户端证书，EKS节点组按实例类型分类管理。

「Note: This setup is for demonstration. For production-grade architectures, always refer to aws-ia to align with AWS best practices.」

他特意加了这句免责声明。演示归演示，但生产环境的坑他已经帮你标出来了。

二、VPN隧道：工程师的"隐形斗篷"

控制平面进私有子网后，本地机器直接失联。

解决路径是：先连VPN，把VPC网段路由进隧道，再让kubectl走这条暗道。具体指令很朴素——sudo openvpn --config client.ovpn，然后aws eks update-kubeconfig更新凭证。

成功后的反馈也很朴素：一行节点列表，STATUS全是Ready。

这套流程的隐藏成本在于：每次新同事 onboarding，都要重复一遍证书分发、路由配置、权限同步。Terraform在这里的价值不是"自动化"，而是把"人可能搞砸的步骤"变成"代码里的一次性定义"。

三、Kyverno进场：给集群雇了个"安检员"

基础设施锁死后，战场转向工作负载。

Kyverno（发音类似"Govern No"，治理之否）的定位很直白：用Kubernetes原生的方式管理策略。不引外部DSL，不写Rego语言，YAML即策略。

安装两条命令：

helm repo add kyverno https://kyverno.github.io/kyverno/

helm install kyverno --namespace kyverno --create-namespace kyverno/kyverno

再搭个可视化看板：

helm install policy-reporter policy-reporter/policy-reporter --set ui.enabled=true --set kyvernoPlugin.enabled=true

现在集群里多了两个常驻角色：Kyverno本身（Webhook拦截器+策略引擎），以及policy-reporter（把违规事件翻译成人类能读的仪表盘）。

四、两种执法模式：自动修正 vs 事后审计

Kyverno的运作逻辑分两支。

Enforce模式：请求进集群时直接改写。比如强制给Pod塞securityContext，把runAsUser从0改成非零值。用户无感知，但容器启动参数已被篡改。

Audit模式：只看不拦，违规事件进日志、进看板、进告警通道。适合灰度上线——先观察哪些工作负载会踩线，再决定要不要一刀切。

工程师的测试案例很典型：给Nginx套一个PSS Restricted级别的变异策略，结果Pod进入CrashLoopBackOff。因为官方镜像默认以root启动，而Restricted规则禁止这种行为。

这里的微妙之处在于：安全策略与业务可用性的冲突，被提前暴露在了预发环境，而不是生产故障里。

五、拆解那张核心图：从"能跑"到"敢跑"

回到那张架构图（https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2026%2F0429%2F6a6f4db7j00te9gsj000td000lq00dnp.jpg&thumbnail=660x2147483647&quality=80&type=jpg），我们可以逐层翻译它的设计意图。

第一层，网络隔离。不是"加个防火墙规则"那种敷衍，而是物理意义上的不可达——控制平面没有公网IP，没有NLB，没有API Gateway。攻击者即使拿到AK/SK，也得先攻破VPN才能摸到API服务器。

第二层，身份收敛。所有管理流量收敛到堡垒机，堡垒机的访问日志成为单一审计源。Terraform在这里确保：堡垒机的安全组规则、IAM角色、密钥轮换周期，全是代码化的、可回滚的。

第三层，策略即代码。Kyverno的策略是Kubernetes对象，意味着它们享受同样的版本控制、CI/CD流水线、回滚机制。安全团队不再发PDF规范，而是发Git PR。

第四层，可观测闭环。policy-reporter把策略违规事件从etcd的深渊里捞出来，变成UI上的红黄绿灯。安全工程师终于不用写grep脚本扒审计日志了。

六、这套方案的"不性感"之处

值得注意的反而是作者没吹的部分。

没有服务网格。没有零信任架构。没有eBPF内核探针。就是VPC子网划分+VPN隧道+一个CNCF沙箱项目（Kyverno 2020年才进入CNCF，2022年毕业）。

这种克制本身是一种信号：Kubernetes安全的主流痛点，可能不在"炫技式创新"，而在"基础工程纪律的落地"。

另一个隐藏细节：作者反复强调aws-ia（AWS Infrastructure Automation）作为生产参考。这意味着演示代码有意做了简化——比如单可用区部署、固定实例类型、无自动扩缩容。抄作业的时候得自己补这些坑。

七、为什么这件事现在值得看

三个背景叠加。

一是EKS的默认配置仍在"方便上手"和"安全合规"之间摇摆。控制平面公网可访问、节点IAM角色过度授权、Pod安全标准未启用——这三项在新集群里全是开着的。

二是Terraform在Kubernetes生态的地位微妙。Crossplane和Pulumi喊了多年"替代"，但Terraform的模块生态（尤其是aws-ia的成熟度和）仍是企业采购的硬指标。

三是Kyverno vs OPA Gatekeeper的战争进入尾声。OPA的Rego语言学习曲线陡峭，Kyverno的YAML原生策略对存量DevOps团队更友好。CNCF毕业项目的背书，正在加速这一分化。

这位工程师的选择，本质上是一次"保守派激进主义"：用最成熟的工具链，解决最基础的攻击面问题。

八、给你的 checklist

如果你正在规划类似架构，这张图里的决策点可以抄：

网络层：控制平面是否必须公网可达？如果团队100%远程，VPN是刚需；如果有固定办公区，专线+PrivateLink可能是更优解。

接入层：堡垒机用OpenVPN还是AWS Client VPN？前者免费但自运维，后者按连接计费但免证书管理。作者的Terraform模块选了前者，成本敏感型团队注意权衡。

策略层：Kyverno的mutation功能启用前，务必在audit模式跑够流量样本。自动改写容器配置可能引发意想不到的业务中断——那位Nginx的CrashLoopBackOff就是预警。

可观测层：policy-reporter的UI是锦上添花，但它的Webhook输出可以直联SIEM。安全团队更关心的可能是后者。

最后，定期回访aws-ia的更新。AWS的Well-Architected框架每季度微调，Terraform模块的best practice也会跟进。演示代码的生命周期，取决于你维护它的决心。

那位Nginx容器至今仍在CrashLoopBackOff里循环。它不会知道，自己的反复崩溃证明了一套安全策略的有效性。这或许就是基础设施工程师的黑色幽默：系统越安全，业务越难跑；业务跑顺了，又怀疑安全是不是摆设。 Kyverno的存在，就是让这种怀疑有个具体的报错对象。