在入侵类应急响应中，客户最常见的诉求之一是：“帮我判断数据库到底有没有被黑客拖库？” 但数据库类型种类众多，每种数据库的拖库手法、留下的痕迹、可用的取证手段都不一样；而且是否开启了审计日志，直接决定了能拿到的证据等级。
本文在腾讯云上用 tccli 真实开通了 7 种托管数据库，插入 10 万行/文档级别的敏感样本数据（身份证、手机号、银行卡、密码哈希），分别在 不开审计 / 开启审计 两种情况下模拟拖库；并对其中差异最大的 SQL Server、Elasticsearch、Redis、MySQL、PostgreSQL 额外做了「自建 vs 托管」对照实测（自建实例上启用原生审计、复现托管版封掉的危险能力）。每个结论都附实际抓取的日志/截图，最后给出应急响应取证清单与加固建议。
全文所有日志、命令、API 输出均为真实实测结果。
阅读更多Shadow API Server（影子 API 服务器）是更顽固的持久化方式——攻击者在 master 节点上 部署第二个 kube-apiserver 进程，它连接相同的 etcd，但完全绕过 RBAC 鉴权。 即使防御方清空所有 ClusterRoleBinding、轮换所有证书，只要这个进程还在，集群就还是攻击者的。
攻击者（已获取 master root 权限）
│
├─ 1. 读取 /etc/kubernetes/manifests/kube-apiserver.yaml
│ 获取 etcd 连接参数、证书路径、镜像版本
│
├─ 2. 写入恶意 Static Pod Manifest
│ /etc/kubernetes/manifests/kube-scheduler-extender.yaml
│ 关键参数：--authorization-mode=AlwaysAllow --secure-port=6444
│
├─ 3. kubelet 自动拉起 shadow kube-apiserver（端口 6444）
│ 连接相同 etcd，但 --authorization-mode=AlwaysAllow 无视 RBAC
│
├─ 4. 用集群 CA 签发的任意证书连接 6444
│ → 不受 RBAC 约束，全集群读写权限
│
└─ 5. 防御方清空 RBAC / 轮换证书 → 无效
shadow API server 依然存在，kubelet 会自动重启它
阅读更多 攻击者
│
├─ 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 对已植入的后门无效，因为后门使用独立的身份凭证。
近2年的应急响应案例中，k8s的入侵案例逐渐增多。并且多次遇到客户云上内网被入侵后黑客窃取了KubeConfig文件，从公网远程调用ApiServer创建容器获取Node服务器权限植入后门的案例。
开发者/CI 系统的 kubeconfig 文件泄露到 Git / 日志 / 备份
│
▼ 黑客获取该文件
黑客在公网直接调用 apiserver（6443 端口）
│
▼ 权限确认为 cluster-admin
黑客创建一个特权 Pod，挂载宿主机根目录
│
▼ kubectl exec 进容器
chroot / nsenter 拿到 Node 宿主机的 root shell
│
▼
完全控制该 Node 宿主机
泄露途径非常多样：.kube/config 被 git add -A 带进仓库、CI 流水线打印了 KUBECONFIG 环境变量、开发者把 kubeconfig 存到共享网盘……一旦泄露，攻击者就能以持有人的身份操作集群，而集群本身不会有任何告警。