如何在AWS EKS集群中安全管理Kubernetes Secrets？

首先明确：用kubectl或Helm从本地部署K8s Secrets确实存在高风险——Secrets以base64编码（本质明文）存储在etcd中，本地部署过程还可能导致敏感信息泄露在终端历史、CI日志或本地配置文件里。以下是适配EKS的安全方案，按优先级和场景分类：

一、AWS原生集成方案（优先推荐） #

1. AWS Secrets Manager + AWS Secrets and Configuration Provider (ASCP) #

这是EKS环境下最省心的原生方案，核心是避免在K8s集群中存储任何Secret对象，直接从AWS Secrets Manager动态挂载到Pod：

• 部署ASCP CSI驱动到EKS集群（可通过eksctl或Helm一键安装）
• 利用IAM Roles for Service Accounts (IRSA) 给Pod绑定最小权限的IAM角色，仅允许访问所需的Secrets Manager资源
• 在Pod配置中定义CSI卷，指定要挂载的Secret ARN，容器内直接读取挂载的文件即可获取敏感信息
• 优势：自动支持Secret轮换、细粒度权限控制、无需维护额外第三方服务，完全适配AWS生态

2. AWS Systems Manager Parameter Store #

适合存储轻量级敏感配置或参数，成本比Secrets Manager更低，同样支持通过ASCP驱动动态挂载，或在应用中通过AWS SDK直接拉取，搭配IRSA实现权限隔离。

二、第三方工具方案（适配跨云/复杂场景） #

1. HashiCorp Vault #

适合多云/混合云环境，支持多种Secret引擎（数据库、云服务、K8s等），提供细粒度访问控制和审计日志：

• 在EKS中部署Vault时，建议用IRSA给Vault授权访问AWS资源，同时启用Vault Agent Injector，自动为Pod注入Secrets，无需手动配置
• 注意：需要维护Vault集群的高可用和备份，有一定运维成本，适合对Secret管理有高级需求（如动态生成数据库账号、多租户隔离）的场景

2. Mozilla SOPS #

轻量级加密工具，专门用来加密K8s YAML中的敏感字段，支持AWS KMS、GCP KMS等作为加密密钥：

• 加密后的YAML文件可安全存储在Git仓库中，部署时通过SOPS解密，完美适配GitOps流程（如Argo CD、Flux）
• 优势：无需在集群中部署额外组件，仅在CI/CD或本地部署环节做解密操作，避免明文Secrets暴露

3. Bitnami Sealed Secrets #

将普通K8s Secrets加密为SealedSecret对象，只有部署该Controller的EKS集群能解密：

• 加密后的SealedSecret可存入Git，集群中的Sealed Secrets Controller会自动将其解密为普通Secrets
• 注意：解密后的Secrets仍会以base64形式存储在etcd中，安全性略低于动态挂载方案，但比明文Secrets更安全

三、最优安全实践总结 #

• 首选AWS原生方案：Secrets Manager + ASCP + IRSA，无额外运维成本，彻底规避K8s Secret存储风险，同时利用AWS的自动轮换和审计能力
• GitOps场景：优先选SOPS，灵活性更高，支持多密钥管理服务；若依赖K8s原生资源格式，可考虑Sealed Secrets
• 跨云/高级需求场景：选择HashiCorp Vault，满足复杂权限控制和多环境统一管理需求
• 通用安全准则：
  • 绝不将明文Secrets存入Git、终端历史或CI日志
  • 始终用IRSA给Pod分配最小必要权限，避免节点角色过度授权
  • 开启Secret自动轮换机制，定期更新敏感信息
  • 启用审计日志（AWS CloudTrail或Vault审计），监控Secret访问行为

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