Linux 上 Kubernetes 的安全保障实践
一 基础架构与版本
- 保持集群与组件为最新稳定版本，及时获取安全补丁与修复，降低已知漏洞风险。
- 对控制面与节点操作系统执行最小化安装与及时补丁，仅开放必要端口与服务，减少攻击面。
- 为主机与节点间、组件间通信启用TLS 加密，避免明文传输敏感信息。
- 对关键配置文件与证书实施严格的权限与所有权控制，例如 API Server、Controller Manager、Scheduler、Kubelet 的 Pod 规范与 PKI 目录，防止被非授权篡改。
二 身份与访问控制
- 对所有 API 交互启用TLS，强制双向认证（客户端证书或对接 OIDC/LDAP 等），确保人、节点、组件均被识别。
- 使用 RBAC 实施最小权限原则：按命名空间与集群范围精细授权，定期审计 Role/ClusterRole 与 RoleBinding/ClusterRoleBinding。
- 启用 NodeRestriction 准入插件，限制 kubelet 仅能操作自身节点对象，缩小提权路径。
- 避免为 kubelet 使用 AlwaysAllow 等宽松授权模式，改用基于证书的精细化授权。
三 工作负载与镜像安全
- 使用 Pod Security Standards（替代 PSP） 或准入控制器（如 ImagePolicyWebhook）统一约束工作负载：禁止特权容器、限制 HostPath/Volume、开启 readOnlyRootFilesystem、收紧 Linux Capabilities、设置 runAsNonRoot、控制 allowPrivilegeEscalation。
- 通过 securityContext 在 Pod/容器级落实用户、权限与文件系统隔离策略。
- 仅允许运行来自受信/私有镜像仓库的镜像，结合 CI/CD 集成镜像扫描（如 Clair、Trivy 等）与签名校验，阻断含漏洞或恶意镜像进入生产。
四 网络与数据安全
- 使用 NetworkPolicy 实现命名空间与服务间的默认拒绝（Default Deny）与最小连通，仅对白名单流量放通；选择支持 NetworkPolicy 的插件（如 Calico、Cilium）。
- 对 Etcd 通信全链路加密与双向认证：启用 –cert-file/–key-file、–client-cert-auth、–peer-cert-file/–peer-key-file、–peer-client-cert-auth，并避免与 API Server 共用授权证书。
- 对敏感数据使用 Secrets 并在传输与静态场景启用加密；结合 RBAC 控制 Secrets 的访问范围。
五 运行时防护 审计监控与合规
- 启用 审计日志（Audit Logs） 记录关键 API 调用，集中到 SIEM 进行关联分析，及时发现异常行为。
- 部署 运行时安全 工具（如 Falco、Sysdig）进行系统调用与容器行为监测，识别容器逃逸、特权滥用等威胁。
- 建立 漏洞管理与补丁流程：定期扫描镜像与节点、滚动更新工作负载，避免运行期就地修改。
- 对控制面组件进行安全加固：如 Kube-scheduler/Controller-manager 绑定 127.0.0.1、关闭不必要接口（如 –profiling=false）、为 Kubelet 设置 anonymous-auth=false、readOnlyPort=0、tls-cert-file/tls-private-key-file、开启证书轮换（如 RotateKubeletServerCertificate）。