Kubernetes 安全加固清单：从 RBAC 到 etcd 加密的生产实践

在云原生时代Kubernetes 已成为容器编排的事实标准但默认配置下的 K8s 并不安全。一次错误的 RBAC 权限配置、一个暴露的 etcd 端口、或者一个特权模式的 Pod都可能成为攻击者的入口。本文从认证授权、Pod 安全、网络隔离、数据加密四个维度整理一份可直接落地的加固清单。一、RBAC最小权限是铁律RBAC基于角色的访问控制是 K8s 权限管理的核心。很多人图省事给 ServiceAccount 直接绑定cluster-admin角色这在测试环境可以但生产环境等于裸奔。最小权限原则的正确做法是先定义应用实际需要的权限再精确授予。以下是一个典型前端应用只读场景的 Role 示例apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:namespace:defaultname:frontend-read-onlyrules:-apiGroups:[]resources:[configmaps,secrets]resourceNames:[app-config,db-credentials]# 精确到具体资源名verbs:[get,list]如果你需要跨命名空间授权使用RoleBinding本命名空间或ClusterRoleBinding集群级别。ClusterRoleBinding要格外谨慎绑定的cluster-admin角色要确认 subject 只能是必要的 ServiceAccount不要用system:authenticated这种通配符apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRoleBindingmetadata:name:monitoring-readersubjects:-kind:ServiceAccountname:prometheusnamespace:monitoringroleRef:kind:ClusterRolename:cluster-monitoring-viewapiGroup:rbac.authorization.k8s.io建议定期用kubectl auth can-i --list --assystem:serviceaccount:ns:sa检查每个 ServiceAccount 的实际权限清理无用绑定。二、Pod Security Standards别让容器拥有不该有的能力K8s 从 1.25 起将 Pod Security Policy 替换为 Pod Security StandardsPSS通过命名空间标签定义三个级别的安全策略privileged最高权限、baseline最低要求、restricted生产推荐。将命名空间标记为restricted级别apiVersion:v1kind:Namespacemetadata:name:productionlabels:pod-security.kubernetes.io/enforce:restrictedpod-security.kubernetes.io/enforce-version:latestpod-security.kubernetes.io/warn:restrictedpod-security.kubernetes.io/warn-version:latestrestricted策略会强制要求禁止特权模式、禁止以 root 运行、只允许受控的 capabilities、必须使用只读根文件系统。例如一个合法的 non-root 容器 Pod specsecurityContext:runAsNonRoot:truerunAsUser:10000seccompProfile:type:RuntimeDefaultallowPrivilegeEscalation:falsereadOnlyRootFilesystem:truecapabilities:drop:-ALL如果你需要在 Pod 中挂载特定 capabilities比如CAP_NET_BIND_SERVICE用于绑定低端口要逐个声明而非全部放开capabilities:add:-NET_BIND_SERVICEdrop:-ALL三、网络策略默认拒绝按需放行K8s 网络模型默认是全通行的同一集群内的 Pod 可以自由互相访问。攻击者一旦拿到某个 Pod往往能横向渗透到整个集群。解决方案是给每个命名空间设置默认拒绝规则再按需放行。默认拒绝所有入站流量apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:default-deny-ingressnamespace:productionspec:podSelector:{}policyTypes:-Ingress放行 Web 层访问后端服务apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:allow-web-to-apinamespace:productionspec:podSelector:matchLabels:app:api-serveringress:-from:-podSelector:matchLabels:app:web-frontendports:-protocol:TCPport:8080需要注意的是网络策略需要有 CNI 插件支持才能生效Flannel 默认不支持推荐使用 Calico、Cilium 或 WeaveNet。四、Secrets 管理别把敏感信息明文存放Kubernetes Secrets 默认只是 Base64 编码未经加密存储在 etcd 中任何有 etcd 访问权限的人都能直接读取。最小化处理是开启 Secrets 的加密apiVersion:apiserver.config.k8s.io/v1kind:EncryptionConfigurationresources:-resources:-secretsproviders:-aescbc:keys:-name:key1secret:base64-encoded-32-byte-key-identity:{}# 回退provider不能删然后在 kube-apiserver 启动参数中指定配置--encryption-provider-config/etc/kubernetes/enc/encryption-config.yaml生产环境中更推荐使用外部 Secrets 管理方案HashiCorp Vault通过 CSI 驱动挂载、AWS Secrets Manager EKS IAM Roles for Service Accounts、或者 Mozilla SOPS 配合 KMS 加密。这类方案的优势在于 Secrets 不会出现在 K8s API 层审计日志也更完整。日常使用中还要注意不要用kubectl create secret generic时直接暴露明文用--from-literal或--from-file不要在 Pod 环境变量中引用 Secrets 而是使用 volume 挂载这样重启才能感知变更。五、etcd 加密护住 K8s 的数据心脏etcd 存储了 K8s 整个集群的状态数据包括 Secret、RBAC 配置、Pod 定义等。一旦 etcd 被攻破攻击者就拿到了整个集群。etcd 加密是最后一道防线。开启 etcd 数据加密静态加密# 生成一个 32 字节的加密 key注意是原始字节不是 base64 字符串ENCRYPTION_KEY$(head-c32/dev/urandom|base64)# 写入 encryption configcat/etc/kubernetes/enc/encryption-config.yamlEOF apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret:${ENCRYPTION_KEY}- identity: {} EOF同时确保 etcd 的通信也是 TLS 加密的启动参数大致如下etcd\\--cert-file/etc/kubernetes/pki/etcd/server.crt\\--key-file/etc/kubernetes/pki/etcd/server.key\\--client-cert-authtrue\\--trusted-ca-file/etc/kubernetes/pki/etcd/ca.crt\\--listen-client-urlshttps://127.0.0.1:2379etcd 数据目录的磁盘加密也不能忽视生产环境建议用 LUKS 或云厂商的加密磁盘防止物理磁盘泄露导致的数据暴露。加固检查清单以下是生产级 K8s 集群上线前必须通过的检查项kube-apiserver 开启--anonymous-authfalse禁止匿名访问kube-apiserver 开启--authorization-modeRBAC,Nodekube-apiserver 关闭不爱用的服务端口如 kubelet HTTPS API 不暴露在外网etcd 仅监听本地或通过安全网络访问不对外网暴露 2379/2380 端口所有命名空间设置了 Pod Security Standards 标签ServiceAccount 不绑定 cluster-admin遵循最小权限Secrets 开启静态加密aescbc 或更好的 KMS 插件etcd 通信使用 TLS不使用 insecure 模式网络策略至少在关键命名空间production、data启用默认拒绝定期审计日志kubectl get events --all-namespaces --watch安全加固不是一次性工程而是持续运营的过程。建议配合 Falco 做运行时威胁检测配合 OPA Gatekeeper 做策略即代码Policy-as-Code用自动化工具保障每次部署都不违背安全基线。防守的深度取决于攻击者的投入成本。做好这些基础加固足以让大多数自动化扫描工具和初级攻击者止步。