k8s-kubeconfig泄露后的RBAC持久化后门排查
攻击者
│
├─ 1. 使用泄露 kubeconfig 连接公网 apiserver
│
├─ 2. 创建后门 ServiceAccount(伪装成系统组件名)
│
├─ 3. 创建 ClusterRole(全权限)
│
├─ 4. 创建 ClusterRoleBinding(将后门 SA 绑定到 cluster-admin)
│
├─ 5. 用 TokenRequest API 生成长期 token(不存储在 apiserver,难以追踪)
│
└─ 6. 防御方删除原始 kubeconfig 对应的 RBAC binding
↓
原始 kubeconfig → Forbidden (请求被拒绝)
后门 SA token → cluster-admin 全权限 (仍能正常使用)
经验丰富的攻击者拿到一份泄露的 kubeconfig(cluster-admin 权限)后,第一件事可能不是立刻操作,而是先给自己埋一个独立的后门——即使原始 kubeconfig 被吊销,后门依然有效。kubeadm certs renew 和删除 ClusterRoleBinding 对已植入的后门无效,因为后门使用独立的身份凭证。
