如何通过Pod工作负载身份从AKS访问HashiCorp Vault密钥

你的核心需求是通过AKS Pod的工作负载身份，借助Vault的Azure认证方式安全获取密钥，下面针对你提到的三个方案逐一分析，并给出适配当前AKS工作负载身份的最佳实践：

方案1：代码嵌入Vault令牌获取逻辑 #

• 优点：逻辑直接，和Azure其他服务的认证逻辑对齐，无需额外依赖第三方组件
• 缺点：侵入业务代码，开发者要维护Vault SDK相关逻辑，违背Kubernetes「基础设施与业务解耦」的思路，密钥轮换时还得调整代码，运维成本高

方案2：使用Vault Operator #

• 优点：Operator模式能自动化Vault资源的生命周期管理，比如Secret引擎、角色的创建和维护
• 缺点：当前版本不支持Pod工作负载身份认证，必须依赖Kubernetes Secret存储凭据，完全违背了用工作负载身份减少密钥暴露的初衷，多了一个安全风险点

方案3：使用Vault Injector（Sidecar模式） #

• 优点：无需修改业务代码，Sidecar容器自动完成Vault认证、密钥获取与挂载，密钥轮换时能自动更新挂载的文件或环境变量，对业务完全透明
• 关键确认：Vault Injector完全支持Pod工作负载身份——只要在Vault的Azure认证角色中绑定对应的AKS工作负载身份客户端ID，同时给Injector的ServiceAccount配置对应的工作负载身份权限，让Injector能代表Pod完成Azure AD认证拿到Vault令牌，最终把密钥挂载到应用容器的指定路径即可

最佳实践推荐 #

优先选择Vault Injector（Sidecar模式），原因如下：

1. 完美适配AKS工作负载身份：通过Vault Azure认证角色关联工作负载身份ID，配合Injector的工作负载身份权限，实现全程无静态密钥的认证流程，符合云原生安全规范
2. 业务零侵入：开发者无需关注密钥获取逻辑，专注业务代码开发即可，降低维护成本
3. 自动化密钥管理：支持自动密钥轮换、动态挂载，减少手动运维操作
4. 安全性更高：避免业务代码直接接触Vault令牌，减少凭据泄露的风险

核心配置要点 #

• 在Vault中开启Azure认证方法，创建绑定AKS工作负载身份客户端ID的认证角色
• 给Vault Injector的ServiceAccount配置AKS工作负载身份，赋予其访问Azure AD获取令牌的权限，用于向Vault完成认证
• 在应用Pod的Deployment中添加vault.hashicorp.com/agent-inject: "true"这类注解，指定要获取的Vault密钥路径、挂载路径等参数
• 确保AKS集群已启用工作负载身份，应用Pod的ServiceAccount关联对应的工作负载身份

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