Vault Agent边车容器比initContainer更适合动态凭据，因其能持续监听secret变更并自动重载，而initContainer仅启动时拉取一次；正确配置需启用auto_auth+templated_secret、设置正确注解与权限、确保serviceAccount绑定kubernetes auth method，并实现应用层文件监听与安全连接池切换。
Vault Agent 注入边车容器为什么比 initContainer 更适合动态凭据
因为 Vault Agent 能持续监听 Vault 中的 secret 变更，并自动重载应用凭证，而 initContainer 只在 Pod 启动时拉取一次，无法响应后续轮转。实际部署中常见错误是误用 initContainer 拉取 database/creds/app-role 后写死进 volume，导致凭据过期后服务持续失败却无报错。
正确做法是启用 Vault Agent 的 auto_auth + templated_secret 模式，让边车容器在内存中维护 token 并按需渲染模板。关键点：
-
vault.hashicorp.com/agent-inject注解必须设为"true"，否则 Kubernetes webhook 不触发注入 - Pod serviceAccount 必须绑定 Vault 的
kubernetesauth method 对应 role，且该 role 的bound_service_account_names要精确匹配 - 模板路径如
/vault/secrets/db-creds.tpl需声明为vault.hashicorp.com/agent-inject-template-db-creds注解，名称必须与文件名后缀一致 - 默认 Vault Agent 使用
sh -c 'sleep 3600'作为 sidecar 启动命令，若应用容器启动太快，可能读不到已渲染的文件——建议加readinessProbe检查/vault/secrets/db-creds是否存在且非空
如何配置 Vault Kubernetes Auth Method 以支持 Pod 级别身份验证
Vault 默认不信任 K8s 集群身份，必须显式配置 kubernetes auth method 才能让 Pod 用 serviceAccount token 换取 Vault token。最容易被忽略的是 token_reviewer_jwt 和 kubernetes_host 的来源——它们不能手写，必须从 K8s API server 的 service account token secret 中提取：
- 运行
kubectl get secret $(kubectl get sa default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 -d获取 reviewer token -
kubernetes_host应设为https://kubernetes.default.svc:443（不是https://10.96.0.1:443，后者在某些托管集群上不可达） - role 绑定时，
bound_service_account_namespaces若设为["*"]，Vault 会拒绝——必须显式列出 namespace，如["prod", "staging"] - 权限策略里不要直接给
read权限到secret/data/*，而是限定路径如read权限到database/creds/app-role，避免凭据泄露面扩大
使用 vault.hashicorp.com/agent-inject-secret-xxx 注解时的路径与权限陷阱
注解名中的 xxx 必须和模板内 {{ with secret "database/creds/app-role" }}... 引用的路径完全一致（包括前缀），否则 Vault Agent 渲染失败但不报错，只会输出空文件。典型错误现象是应用启动时报 failed to open /vault/secrets/db-creds: no such file or directory，但 ls /vault/secrets/ 显示目录为空。
- 所有注入路径默认挂载为
0600权限，若应用容器以非 root 用户运行（推荐），需通过securityContext.runAsUser与vault.hashicorp.com/agent-run-as-user注解保持 UID 一致 - 若 secret 路径含版本号（如
kv-v2/data/app），必须用data子路径：即写kv-v2/data/app而非kv-v2/app，否则返回permission denied - 模板中避免硬编码
field名称，比如{{ .Data.data.password }}在 kv-v2 中才有效；kv-v1 应用{{ .Data.password }}，混用会导致渲染为空
凭据轮转时应用如何安全感知并重载连接池
Vault Agent 不会主动通知应用凭据已更新，轮转生效依赖两个机制：Agent 自动重写文件 + 应用监听文件变更。很多团队只做了前者，结果数据库连接持续失败数小时。
- Vault Agent 默认每 5 秒检查一次 secret 版本，可通过
vault.hashicorp.com/agent-inject-status注解设为"update"开启增量更新（仅改字段变化部分） - 应用层必须实现文件 inotify 监听，例如 Go 用
fsnotify监控/vault/secrets/db-creds，Java 可用WatchService，Python 推荐watchdog - 重载时禁止直接 close 原连接池——应先建新池、校验连通性、再原子切换引用、最后 close 旧池，否则出现短暂雪崩
- 务必在 Vault policy 中限制
renew权限，否则攻击者可能通过延长 token 有效期绕过轮转策略
最常被跳过的一步是：没在 Vault 中为对应 role 设置 max_ttl，导致凭据永不轮转。哪怕后端策略写了 1h TTL，若 role 的 max_ttl = 0，Vault 就允许无限续期。
