如何避免Kubernetes集群管理员读取Vault sidecar注入的明文密钥？

最优方案：应用直接对接Vault拉取密钥 #

完全放弃侧车明文注入文件的模式，从根源避免密钥落地：

• 应用自身通过Vault API拉取所需密钥，密钥仅在应用运行内存中留存，不会写入Pod的任何存储卷
• 身份认证采用Vault原生Kubernetes Auth方法，由Vault管理员配置规则，将应用专属Service Account与密钥访问权限绑定，仅该SA有权限拉取对应应用的密钥，权限完全由Vault侧管控，K8s管理员无法通过修改集群配置越权获取
• 就算K8s管理员执行kubectl exec -it <pod>进入Pod，也无法从文件系统读取到明文密钥，除非能Dump应用运行内存，攻击成本大幅提升

兼容方案：优化现有侧车注入逻辑（适用于应用改造成本高的场景） #

如果无法改造应用对接Vault，可以通过以下多层策略降低风险：

• 替换共享卷为内存卷：将/vault/secrets对应的存储卷设置为emptyDir.medium: Memory，密钥完全存储在内存中，不会落盘到节点存储，避免节点层面的泄露风险
• 收紧文件与容器权限：侧车注入密钥文件时指定权限为0600，侧车和应用容器使用相同的非Root UID运行，配合Pod Security Restricted策略禁止Root用户执行、禁止特权容器、禁止权限提升，就算管理员exec进入容器，也只能以应用UID身份操作，无法越权读取文件
• 启用动态短期凭证：将静态密钥替换为Vault动态生成的短期凭证，默认有效期设置为几分钟到几小时，自动轮转，就算管理员意外拿到密钥，短时间内就会失效，大幅降低泄露后的危害
• 收紧K8s RBAC权限：通过RBAC规则限制集群管理员对生产命名空间下Pod的exec、cp等敏感操作权限，仅允许特定应急账号在审计日志全程记录的前提下操作，所有操作留痕可追溯

补充方案：对接Secrets Store CSI Driver #

替换侧车注入方案为Kubernetes Secrets Store CSI Driver对接Vault，将密钥直接挂载到容器的加密内存卷，可配置不将密钥同步为Kubernetes原生Secret，避免etcd层面的密钥泄露风险。

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