自托管Kubernetes集群安全需严控etcd、API Server、节点配置、RBAC及运维责任：etcd须禁用未授权访问并启用双向TLS；API Server须禁用匿名访问与非加密端口；Worker节点需禁用特权容器、加固内核、限制hostPath；ServiceAccount应禁用自动挂载Token、遵循最小权限原则；还需持续开展证书轮换、备份演练与内核补丁同步。
自托管 Kubernetes 集群（即非托管服务如 EKS、AKS、GKE，而是用 kubeadm、kops 或手动部署）在获得完全控制权的同时，也把所有安全责任和配置细节直接压到了运维者肩上。不设防的自托管集群，往往等于把 etcd、API Server 和节点凭证裸露在攻击路径上。
etcd 未授权访问：最致命的配置失误
etcd 是集群的“大脑”，存着所有 secrets、token、RBAC 规则。一旦暴露，攻击者可直接 dump 全量凭据并创建高权限 Pod。
- 错误做法：
listen-client-urls=http://0.0.0.0:2379+client-cert-auth=false，等同于把数据库密码贴在门口 - 正确做法：只监听
https://127.0.0.1:2379，强制启用 TLS，并用--trusted-ca-file和--cert-file配置双向认证 - 验证命令：
curl -k https://localhost:2379/health应返回 401；若返回{"health":"true"}，说明未启用认证或监听地址错误
API Server 暴露与匿名访问漏洞
API Server 是集群唯一入口，若配置宽松，攻击者无需凭证就能调用 /api/v1/secrets 或创建恶意 ServiceAccount。
- 必须禁用匿名请求：
--anonymous-auth=false（默认为 true，极易被忽略） - 禁止非加密端口：
--insecure-port=0，否则http://master:8080可直连读取资源 - 限制绑定地址：
--bind-address=127.0.0.1或内网 IP，绝不能是0.0.0.0 - 检查是否生效：
kubectl get --raw /api/v1/secrets --insecure-skip-tls-verify若返回 401 而非 403 或数据，说明认证链已起作用
节点级配置疏漏：从容器逃逸到宿主机沦陷
Worker 节点不是“黑盒”，其操作系统、运行时、内核参数共同构成第一道防线。
- 禁用特权容器：
PodSecurityPolicy已弃用，改用PodSecurity Admission并设置pod-security.kubernetes.io/enforce: restricted - 加固内核参数：确保
/proc/sys/kernel/unprivileged_bpf_disabled=1（防 eBPF 提权）、vm.unprivileged_userfaultfd=0 - 禁用危险挂载：
hostPath类型必须白名单限制，避免映射/etc或/var/lib/kubelet - 运行时隔离：使用 containerd 的
unprivileged模式，或启用 SELinux/AppArmor 策略（如container_t类型约束）
RBAC 与 ServiceAccount 的最小权限陷阱
默认生成的 default ServiceAccount 在每个命名空间都有 system:serviceaccounts:<ns></ns> 组权限，一旦 Pod 被攻陷，就可能横向提权。
- 删除默认 SA 的自动挂载：
automountServiceAccountToken: false，仅对明确需要 API 访问的 Pod 开启 - 避免使用
cluster-admin绑定到任何 ServiceAccount；用RoleBinding替代ClusterRoleBinding，范围限定在命名空间内 - 定期审计：用
kubectl auth can-i --list --as=system:serviceaccount:prod:app-sa检查实际权限是否超出预期 - 警惕
allowPrivilegeEscalation: true—— 它让容器内进程可通过execve()提权，应始终设为false
自托管的本质不是“自己装完就完事”，而是持续承担组件升级、证书轮换、配置漂移检测和日志审计的责任。最容易被跳过的环节，往往是 etcd 备份恢复演练、API Server TLS 证书过期检查、以及节点内核补丁同步 —— 这些不产生日志告警，但一出问题就是 P0 级故障。
