如何使用AppRole方法实现Kubernetes应用与Vault的身份认证

直接将RoleID、SecretID配置为K8s环境变量是否满足安全要求？ #

完全不满足，本质和你之前把DB密码硬编码在部署文件里的风险没有区别。

• RoleID是AppRole的身份标识，本身敏感度不高，但SecretID是登录凭证，等效于密码。一旦直接写在Deployment定义、ConfigMap或者普通环境变量中，所有有权限读取K8s部署资源、能exec进入Pod、能查看Pod环境变量的用户，都能拿到SecretID冒用应用身份拉取Vault内的所有敏感数据，完全违背引入Vault做密钥管理的初衷。
• 哪怕你把这两个值存在K8s原生Secret里再挂载为环境变量，也只是比硬编码在Deployment里稍规范一点，核心风险依然存在：默认集群配置下，所有有Secret读取权限的账号、能进入Pod的账号都能拿到明文凭证。

直白点说，这种配置相当于你给家门换了个高级指纹锁，转头把备用钥匙贴在门锁边上，锁的防护能力完全发挥不出来。

应用侧对接Vault AppRole的标准配置流程 #

核心原则是：RoleID可公开配置，SecretID绝对不能用长期静态值，必须走短有效期、动态下发、单次/限次使用的模式，不要长期固定存放在任何K8s持久化资源里。根据应用改造能力不同，可选两种落地方式：

方案1：应用原生集成Vault SDK（安全性最高，改造量极小） #

• 把Vault服务地址、对应AppRole的RoleID作为普通环境变量配置在Deployment中即可，这两个值不属于敏感信息，不需要特殊加密存储。
• 在K8s集群部署官方的Vault Agent Injector准入组件，给业务Deployment添加对应注入注解，组件会在Pod启动时，基于Pod绑定的Service Account身份，向Vault申请对应AppRole的短有效期、单次使用的SecretID，直接挂载到Pod的内存目录（默认路径为/vault/secrets），不会落盘到节点存储，也不会暴露在环境变量中。
• 应用启动时，先从约定的内存路径读取SecretID，和环境变量中的Vault地址、RoleID组合，调用Vault的AppRole登录接口获取临时访问Token，后续用这个Token拉取DB用户名、密码等所需敏感数据即可。
• 配置建议：给对应AppRole设置的SecretID TTL不要超过10分钟，访问Token TTL结合业务密钥轮换周期设置，建议不超过30分钟，到期后应用自动重新完成认证拉取新凭证，就算凭证意外泄露，可用窗口极短，风险可控。

方案2：无代码改造，用Vault Agent Sidecar代理 #

如果是存量老应用，不方便改代码集成SDK，直接用Sidecar模式即可：

• 同样通过Vault Agent Injector给业务Pod注入Sidecar容器，在Deployment注解中配置好需要拉取的Vault密钥路径、对应AppRole的RoleID，Sidecar会自动完成AppRole认证、Token续期、密钥拉取、凭证轮换的全流程。
• Sidecar会把拉取到的DB账号密码等敏感值写入Pod内的内存文件系统，业务应用直接从约定路径读取配置文件即可，完全不需要感知Vault的存在，部署配置里不需要填写任何敏感凭证。
• 这种模式下你完全不需要手动管理SecretID，Sidecar会基于Pod的Service Account身份动态申请、轮换SecretID，不存在长期静态凭证泄露的风险。

配置避坑提醒 #

• 绝对不要图省事生成永久不过期的SecretID，硬塞到K8s Secret里长期使用，这种做法只是把之前硬编码在Deployment里的DB密码换了个存储位置，安全等级没有本质提升。
• 严格遵循最小权限原则配置AppRole的访问策略，每个应用的AppRole只能读取自身业务所需的密钥路径，禁止配置全路径读取权限，避免单个应用凭证被攻破后波及全集群敏感数据。

内容的提问来源于stack exchange，提问作者Container-Man