北京
某天，一位开发者无意中把包含 AWS IAM 密钥的配置文件推送到了公开代码仓库。几小时后，攻击者已经用那些凭证枚举了云账号，摸进了 Kubernetes 集群，然后植入被投毒的容器镜像，一边横向移动一边收割集群里的所有 Secret。这并非虚构——近年的威胁情报多次记录了这一攻击链，从工作站上的凭据文件（T1552.001）到云账号有效登录（T1078.004），再部署容器（T1610）并劫持资源（T1496），环环相扣。而 Shai‑Hulud 供应链攻击正是专门从 CI 环境和开发者工作站窃取 Kubernetes 凭据，完美复现了这条链路。
一位安全研究员在整理这些案例时，脑子里冒出了三个直白的问题：Kubernetes 的 Secret 到底是什么？攻击者拿到它们能干什么？防御者又该怎么加固集群？要回答这些，先得把最容易被攻击的三张“面”和三种凭据格式理清楚。
从简化视角看，Kubernetes 有三个需要凭证的接触面：第一，开发者或自动化流水线通过 kubectl 调用 API 服务器，这是集群的正门；第二，每个节点上的 kubelet 暴露自己的 HTTPS API，如果网络可达，同一套凭证也能直接认证；第三，节点要从容器仓库（Docker Hub、ECR、Quay 等）拉取镜像，这依赖另一套仓库凭据。揭示这三张攻击面的正是三种凭据格式——TLS 客户端证书、JWT 服务账户令牌，以及容器仓库的 Docker config JSON。
TLS 证书被打包在 kubeconfig 文件里，配合 kubectl 使用。一旦这个文件泄露，就等于把集群拱手交出。一个常见的 kubeconfig 结构如下：clusters 域指定服务器的地址和 CA 证书；users 域里藏着 client‑certificate‑data 和 client‑key‑data，这两段 base64 数据就是真正的凭证；剩下的 contexts 和 current‑context 只是配置。验证这些凭证根本不需要 kubectl——API 服务器本身就是一个 HTTPS 端点。
JWT 服务账户令牌是非人类身份，常被用在 CI/CD 流水线、控制器和各种集成里来自动化操作集群。更要命的是，默认生成的 JWT 没有过期时间，几年前泄露的令牌至今可能依然有效。而容器仓库凭据则是以 kubernetes.io/dockerconfigjson 类型的 Secret 对象存在，本质是一段 base64 编码的 JSON 文档，里面包含了拉取私有镜像所需的认证信息。这三种格式，TLS、JWT、Docker config JSON，正是攻击者探查、验证并利用的重点。
如果能从泄露的 kubeconfig 里抽出证书和密钥，攻击者就拿到了进入 API 服务器的钥匙，可以创建后门容器、窃取更多的 Secret、甚至劫持整个集群的计算资源。而服务账户令牌的长期有效性，让多年未被轮换的凭据成为一颗颗“沉睡炸弹”。集群里存储的容器仓库凭证一旦暴露，攻击者还能篡改镜像，在源头埋入恶意代码。这也正是为什么，从开发者笔记本到 CI 系统，任何一处疏忽，都可能让一条攻击链完整运转起来。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
