K8S入侵运营商SR

K8S入侵运营商SR：一场悄无声息的“内鬼”背叛，我亲眼见证了这场灾难！

哎,朋友们，今天咱们不聊那些虚头巴脑的“云原生趋势”，我非得跟你们掰扯掰扯上周我亲眼目睹的一场“事故”——K8S集群被入侵，直接打进运营商的核心网元SR（业务路由器）！说真的，那一刻我后背的冷汗直接浸透了衬衫……你们敢信吗？一个配置失误，加上一点点社会工程学，整个核心网就像被扒光了衣服，在黑客面前跳芭蕾！

这哪是漏洞，简直是“自家大门挂钥匙”！

事情是这样的,那天下午我正悠哉地调一杯美式，突然监控大屏上K8S集群的Pod调度曲线像心梗病人的心电图一样乱跳，我凑近一看，好家伙！一个名为“network-proxy”的Pod，CPU使用率直接飙到95%！我当时还傻乎乎地以为是谁手滑跑了个数据备份任务，结果点进去一看，丫的根本就不是我们镜像仓库里的东西！

这里我得给你们划重点了——K8S本身不算脆弱，但当它被裸奔在运营商网络里，没有网络策略（NetworkPolicy）限制东西向流量时，那简直是把核心网SR的SSH端口直接暴露在公网上！这帮攻击者就是利用了默认的“Allow All”策略，先打穿了集群里的一个边缘节点，然后像爬水管的老鼠一样，顺着Pod网络摸到了SR的管理网段。

运营商SR：那个被K8S“封死”的老实人

咱们都知道,SR（业务路由器）是运营商骨干网的命根子，平时都是专人专机、物理隔离，可那天，K8S集群里的一个恶意容器，竟然通过挂载宿主机的/var/run/docker.sock（别问我为什么要挂载，问就是“监控需求”），直接逃逸出了容器边界！然后它拿着这个权限，在宿主机上疯狂扫描，愣是找到了跟SR网管系统对接的一个“特批”防火墙规则——你说气不气人？明明有个防火墙，但规则里写着“来自K8S节点池的IP允许访问SR的SNMP端口”！

卧槽，这特么是谁批的规则？ 我当场差点把键盘拍碎！这感觉就像你在家里装了最贵的保险柜，结果钥匙放在门口脚垫底下，还在上面贴了张纸条：“小偷同志，请自取”——咱能怪小偷手贱吗？

入侵过程细思极恐，简直像“内鬼”递刀子

你们猜最阴险的招数是什么？攻击者压根没搞什么高深的0day，人家就是用了K8S的ServiceAccount自动挂载机制！默认情况下，每个Pod里都挂着一个serviceaccount token，而且权限高得吓人，他们先用一个宽松权限的命名空间当跳板，调用了K8S API的pods/exec接口，跑了几个网卡嗅探命令，拿到了SR上一条敏感会话的IP五元组。

他们利用K8S的端口转发功能（kubectl port-forward），在SR网管系统与攻击者控制端之间开了一条加密隧道，整个过程，我们的入侵检测系统（IDS）居然没报警？为什么？因为流量伪装成了K8S的Flannel VXLAN封装格式，跟正常的内部通信混在一起了！这玩意儿在流量视图里，长得跟我同事中午摸鱼看抖音的网络请求一模一样，谁分得清啊！

这场事故给我的三个“血泪教训”（说多了都是泪）

第一,千万别信K8S默认的安全设置！默认的NetworkPolicy是空的，默认的ServiceAccount权限能从API Server拉取所有Pod列表——这哪是默认配置，这分明是给黑客开的VIP通道！我连夜给所有命名空间补了最小权限策略，还把automountServiceAccountToken: false写进了发布的模板里，各位，这可是用SR上的BGP路由表被人偷偷导出的代价换来的经验啊！

第二,容器逃逸不是传说，是宿命！只要是共享内核，只要有docker.sock的挂载，你就别把自己当神，我们后来发现，攻击者甚至用nsenter命令直接进入了宿主机命名空间，改了hosts文件，把SR网管的域名解析指向了一个挖矿的恶意IP——要不是发现得早，这SR的策略路由怕不是要改成“流量绕道莫斯科”了！

第三,运营商的“合规性检查”真的要落到实处！事后翻审计日志，发现一周前就有个外网IP在疯狂扫描K8S的6443端口，当时的告警部门居然因为“日志量太大”给标记为误报了！我当时就骂娘了——这就像你家保险柜的报警器响了，你嫌吵把电池抠了，然后小偷来把你家搬空了还顺手给你浇了盆水……服了！