容器与 Kubernetes 安全加固实践

Kubernetes 是 API 驱动的平台，控制平面、Kubelet 与工作负载三者都可能成为突破口。官方“保护集群安全”文档给出的原则很清晰：先管住谁能访问 API、再限制工作负载的运行时权限、最后保护 etcd 等关键组件。镜像扫描等供应链部分可参考容器安全最佳实践。

现实中很多集群并不是被“高级攻击”攻破的，而是败在默认配置：匿名访问没关、kubelet 裸奔、ServiceAccount 权限过大、Secret 明文存在 etcd 里。攻击者只要拿到一个普通 Pod 的权限，就能顺着这些默认缺口一路放大。下面按“身份 → 运行时 → 数据 → 自动化”的顺序逐层加固。

控制平面访问：认证与授权

TLS：所有 API 流量默认走 TLS，确认安装器没有暴露明文 HTTP 端口；
认证：大集群接入 OIDC/LDAP，节点、代理等基础设施客户端使用 x509 证书或 Service Account；
授权：启用 RBAC，坚持最小权限；建议同时启用 Node 与 NodeRestriction 准入插件，限制 kubelet 与节点权限；
Kubelet：默认允许未认证访问，生产环境务必开启其认证与授权。

最小权限的 RBAC 示例

与其给开发一个“集群只读”的角色，不如只授予其命名空间内需要的资源权限：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: app-developer
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: app
  name: dev-binding
subjects:
  - kind: User
    name: [email protected]
roleRef:
  kind: Role
  name: app-developer
  apiGroup: rbac.authorization.k8s.io

Role + RoleBinding 只作用于单个命名空间，比 ClusterRole + ClusterRoleBinding 的范围小得多。审查现有权限可以用 kubectl auth can-i --list，排查过大的绑定用 kubectl get clusterrolebinding -o wide。

工作负载运行时安全

Security Context：应用容器以非 root 用户运行，去掉不必要的能力（capabilities）；
Pod Security Standards：按命名空间启用 Pod 安全准入，目标为 Baseline 或 Restricted；

启用 Pod 安全准入只需给命名空间打标签，Kubernetes 会自动拒绝不合规的 Pod：

kubectl label --overwrite ns app pod-security.kubernetes.io/enforce=restricted
kubectl label --overwrite ns app pod-security.kubernetes.io/audit=restricted

enforce 会直接拒绝，audit 只记录告警。建议先加 audit 观察一段时间再切 enforce，避免误伤存量工作负载。

内核模块：通过 /etc/modprobe.d/ 黑名单禁用 dccp、sctp 等易出问题的模块，或用 SELinux 阻断 module_request；
网络策略：用 NetworkPolicy 限制跨命名空间访问，并限制 Pod 访问云元数据 API（169.254.169.254）；
资源限制：用 ResourceQuota 与 LimitRange 防止资源耗尽型攻击。

关键组件保护

etcd：只允许 API Server 通过 TLS 互认访问，etcd 具备读写即等同集群管理员；
审计日志：启用 API 审计并归档到安全服务器，对接日志审计；
静态加密：为 Secret/ConfigMap 启用 etcd 静态加密，防止备份泄露；

开启方式是在 API Server 启动参数里加 --encryption-provider-config，指向一个包含 AES-GCM 密钥的加密配置文件。配置生效后，新的 Secret 会以密文写入 etcd，存量数据需要配合轮换脚本重写一次。

凭据轮换：证书与服务账号令牌设置短生命周期并自动化轮换；
第三方集成：上线前审查其权限，警惕"申请读取全部 Secret"等于集群管理员的组件。

加固优先级与落地顺序

资源有限时，按以下顺序推进收益最高：

先管身份：关闭匿名访问，启用 RBAC 与 NodeRestriction，收紧 kubelet；
再限运行时：强制非 root 运行、启用 Pod 安全准入到 Restricted、限制 capabilities 与 seccomp；
后护数据：开启 etcd 静态加密、etcd 网络隔离与审计日志；
最后自动化：把以上规则固化为策略即代码（Policy-as-Code），随集群版本升级持续复核。

镜像与供应链安全

镜像扫描纳入构建流水线，高危漏洞阻断发布，可参考容器安全最佳实践；
使用可信基础镜像并固定版本，避免 "latest" 漂移；
启用镜像签名与不可变标签，防止被替换注入。

常见风险提示

拥有 etcd 读写权限约等于集群管理员，务必最小化并做网络隔离；
第三方组件申请"读取全部 Secret"时高度警惕，这等同于集群管理员权限；
允许在系统命名空间创建特权 Pod 的集成，是容器逃逸的高发路径。

上线前核对清单

在把集群交给业务使用前，逐项确认：API Server 是否走 TLS、是否关闭匿名访问、RBAC 是否最小化、Pod 安全准入是否启用、etcd 是否加密且网络隔离、审计日志是否落盘归档。每项都可以用 kubectl auth can-i --list、kubectl get psa 等命令快速验证，把“默认安全”固化成上线检查项。建议把这份清单固化成团队的上线 SOP：每次新建命名空间或接入新工作负载时，对照检查项逐条过一遍，而不是等到出了问题再回头看。

16IDC 观察

Kubernetes 安全的关键不是某个单一工具，而是"最小权限 + 分层防御"的默认姿态。小团队可以先从命名空间隔离、Pod 安全标准与镜像扫描三项起步，再逐步推进 RBAC 审计与 etcd 加密。入门部署可参考Kubernetes 入门部署。完整体系回到安全加固查看。

参考：Kubernetes 保护集群安全 https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/；Pod 安全标准 https://kubernetes.io/docs/concepts/security/pod-security-standards/；NSA/CISA Kubernetes 加固指南 https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF

原文来源：https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/

容器与 Kubernetes 安全加固实践