生产环境Kubernetes安全部署需全链路约束：关闭Swap并持久化、禁用非白名单内核模块、启用SystemdCgroup、etcd强制双向TLS认证、API Server最小化启动参数、严格管控审计日志与备份权限。
生产环境 Kubernetes 集群安全部署不是“加几个 RBAC 规则”就能收工的事——它是一套贯穿节点、控制平面、网络、镜像、凭证全链路的约束体系。不设最小权限、不隔离 etcd 访问、不校验容器签名，等于把集群钥匙挂在登录页上。
关闭 Swap 并禁用未授权内核模块加载
这是 K8s 1.8+ 的硬性要求，但很多团队只执行 swapoff -a，却忽略持久化和模块管控，导致重启后失效或被恶意模块注入。
- 永久关闭 Swap：
sed -i '/swap/s/^/#/' /etc/fstab（仅注释，避免误删整行） - 禁止非白名单内核模块自动加载：在
/etc/modprobe.d/blacklist.conf中添加install <module_name> /bin/true</module_name>，重点屏蔽nf_nat_ftp、ip_vs_ftp等易被利用的模块 - 验证是否生效：
lsmod | grep -E "(overlay|br_netfilter)"应仅显示必需模块，且cat /proc/swaps输出为空
配置 SystemdCgroup=true 并锁定 containerd 运行时行为
默认 containerd 配置下 SystemdCgroup = false 会导致 cgroup v2 下资源限制失效，CPU/Memory request/limit 形同虚设，还可能引发 kubelet 崩溃。
- 修改
/etc/containerd/config.toml，确保该行存在且为 true：SystemdCgroup = true - 禁用不安全的运行时特性：在 same 文件中设置
disable_cgroup_parent = true和disable_apparmor = true（除非你明确启用并审计过 AppArmor profiles） - 重启生效：
systemctl restart containerd && systemctl status containerd，检查日志中无cgroup parent mismatch类报错
etcd 数据目录与通信通道强制 TLS 双向认证
etcd 是集群的“心脏”，一旦被未授权读写，RBAC、NetworkPolicy 全部失效。默认部署常遗漏 client-to-server 和 peer-to-peer 的双向证书校验。
- 启动 etcd 时必须同时指定：
--client-cert-auth=true、--peer-client-cert-auth=true - etcd 数据目录（如
/var/lib/etcd）需设为700权限，属主为etcd:etcd，禁止 world-readable - 定期轮换证书：使用
etcdctl --cert /pki/etcd/client.pem --key /pki/etcd/client-key.pem --endpoints https://127.0.0.1:2379 endpoint health验证连通性，再替换证书文件
API Server 启动参数强制最小攻击面
默认 kubeadm init 生成的 manifest 往往开启过多非必要功能，比如匿名访问、非加密端口、宽泛的 admission 插件，这些是红队第一波攻击入口。
- 从
/etc/kubernetes/manifests/kube-apiserver.yaml中移除：--insecure-port=0（必须为 0）、--anonymous-auth=false、--enable-admission-plugins中剔除AlwaysAdmit和DenyEscalatingExec（已废弃） - 只保留最小必要插件：至少含
NodeRestriction、PodSecurity、ResourceQuota - 绑定地址必须为
--bind-address=127.0.0.1（本地监听），外部访问走 LB + TLS 终止，而非直接暴露6443
最常被跳过的其实是 etcd 备份策略和审计日志落盘路径的权限控制——没备份的加密证书和没权限保护的 /var/log/kubernetes/audit.log，会让所有前面的配置变成纸面安全。
