K8s安全加固清单：从RBAC到数据加密-编程阁

在云原生时代，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 --as=system:serviceaccount:<ns>:<sa>检查每个 ServiceAccount 的实际权限，清理无用绑定。

二、Pod Security Standards：别让容器拥有不该有的能力

K8s 从 1.25 起将 Pod Security Policy 替换为 Pod Security Standards（PSS），通过命名空间标签定义三个级别的安全策略：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:latest

restricted策略会强制要求：禁止特权模式、禁止以 root 运行、只允许受控的 capabilities、必须使用只读根文件系统。例如一个合法的 non-root 容器 Pod spec：

securityContext: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.yaml<<EOF 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-auth=true\\--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt\\--listen-client-urls=https://127.0.0.1:2379