如何保障K8s集群节点与命名空间中Docker私有仓库凭证安全？

一线团队实际落地的成熟方案 #

• Bitnami Sealed Secrets 轻量加密方案
  这是容器化起步团队用得最多的零外部依赖方案，全程不需要对接第三方密钥API、云厂商KMS：
  • 运行逻辑很直白：客户端侧用kubeseal工具把需要用的镜像拉取凭证（也就是常规的regcred类Secret）加密成SealedSecret自定义资源，这个加密后的文件就算被普通用户拿到、丢在公开Git仓库里，没有集群内部署的Sealed Secrets控制器持有的解密私钥，根本没法还原出明文凭证。
  • 权限边界够清晰：控制器匹配到对应命名空间、对应名字的SealedSecret资源时，会自动解密生成原生K8s Secret，供工作负载通过imagePullSecrets字段直接引用；解密用的私钥默认存在集群内控制器的专属Secret里，只有集群管理员能访问，同命名空间的普通用户既拿不到私钥，也没法从加密的SealedSecret资源里逆推出明文。
  • 部署成本极低，单副本控制器Pod就能支撑中小规模集群的全量Secret加密需求，几乎不占额外资源。
• K8s 原生etcd静态加密方案
  不用装任何第三方插件，纯靠集群原生能力实现加密存储：
  • 很多团队默认部署的集群，会把Secret的Base64编码值直接明文存在etcd里，只要在apiserver配置里加一段本地静态加密规则，用存在apiserver本地节点的密钥做加密（全程不调用外部API），所有落到etcd的Secret（包括镜像拉取凭证）都会用AES算法加密落盘。
  • 刚好匹配安全需求：就算有人拿到etcd的全量备份，没有apiserver本地存的加密密钥，也没法直接从备份里还原凭证明文；再配合严格的RBAC配置，限制普通用户只有通过apiserver鉴权后才能看到解密后的Secret内容，从存储层堵死明文泄露的口子。
• 流水线侧临时注入方案
  不想在集群里装额外控制器的团队，完全可以在CI/CD链路里做全流程凭证隔离：
  • 把加密后的镜像拉取凭证存在Git仓库的加密配置块里，流水线运行时在隔离的安全上下文里，用本地存的解密密钥临时生成imagePullSecrets对应的原生Secret，部署动作跑完立刻销毁临时解密上下文，全程不会在跳板机、操作节点上留长期可用的docker login my.registry.com生成的明文config.json文件。

实际踩坑总结 #

• 别把编码当加密：不管选哪种方案，加密环节都是用标准对称加密算法，原生Secret的Base64编码没有任何防护作用，千万别把这类Base64内容直接丢到公开仓库。
• 从流程上堵漏洞：给命名空间里的普通用户默认不开get secret的RBAC权限，由控制器或者流水线自动把需要的imagePullSecrets绑定到命名空间的默认服务账号上，普通用户根本没有路径读到凭证明文。
• 刚起步的小团队优先选Sealed Secrets：相比从零配置原生etcd静态加密的复杂度，Sealed Secrets只要两步就能部署完——应用自定义资源、跑个控制器Pod，10分钟就能搭完，是起步阶段性价比最高的选择。

内容的提问来源于stack exchange，提问作者cnu