Vault 解决什么问题
playbook 与变量文件要进版本库，但里面常有口令、密钥、连接串。Ansible Vault 用口令派生密钥把文件整体或单个变量的值加密成一段带 $ANSIBLE_VAULT 头部的文本，仓库里只存密文，执行时用口令解密。它是文件级的安全边界，不是权限系统：谁能拿到口令，谁就能读出全部内容。
基本信息
| 子命令 | create、edit、view、encrypt、decrypt、rekey、encrypt_string |
|---|---|
| 口令来源 | 交互式 --ask-vault-pass，或 --vault-password-file 指定的文件（可为可执行脚本） |
| 多口令 | 支持 --vault-id 标签@来源，配置项 vault_identity_list 可固化 |
| 密文形态 | YAML 文件头部为 $ANSIBLE_VAULT，其余为按块输出的密文行 |
| 单值加密 | encrypt_string 生成可直接写进普通变量文件的密文串 |
| 生效范围 | 变量文件、模板源文件、清单中的字符串值等文本资源 |
典型使用场景
- 把含口令的变量文件纳入版本库，而不必排除在仓库之外
- 多个环境共用同一份 playbook，用不同 vault-id 对应不同环境的密钥
- CI 中非交互执行：口令来自受控文件或环境注入的脚本，而不是命令历史
- 团队交接时轮换密钥：用 rekey 一次性换掉口令，历史密文重新加密
- 单点敏感值：用 encrypt_string 只加密一个字段，其余变量保持可读便于评审
- 临时查看密文内容：用 view 打开只读查看，不落盘明文
日常工作流
日常工作流
# 新建一个加密变量文件
ansible-vault create group_vars/prod/vault.yml
# 编辑已有密文（解密到临时文件，退出后重新加密）
ansible-vault edit group_vars/prod/vault.yml
# 只查看内容，不修改
ansible-vault view group_vars/prod/vault.yml
# 轮换口令：把该文件用新口令重新加密
ansible-vault rekey group_vars/prod/vault.yml
# 加密单个值，输出可直接粘贴进明文变量文件
ansible-vault encrypt_string --stdin-name 'db_password' 'S0me-P@ss'
# 执行时提供口令：交互输入或多来源
ansible-playbook site.yml --ask-vault-pass
ansible-playbook site.yml --vault-password-file ~/.ansible/vault_pass.sh
ansible-playbook site.yml --vault-id prod@~/.ansible/prod_pass常用子命令对照
| 子命令 | 作用 | 风险点 |
|---|---|---|
| create | 新建并加密文件 | 口令一旦丢失，内容无法恢复 |
| edit | 解密后编辑再加密 | 编辑期间明文落在临时目录，注意本机环境 |
| view | 只读查看 | 内容会出现在终端滚动记录里 |
| encrypt | 把已有明文文件整文件加密 | 先确认仓库里没有明文历史版本 |
| decrypt | 永久解密成明文 | 最危险的操作，容易把明文提交进仓库 |
| rekey | 更换口令 | 需同时更新所有自动化引用的口令来源 |
| encrypt_string | 加密单个值 | 适合小片段，不适合整文件替换 |
加密文件仍然可以正常参与变量优先级：它只是内容被加密的 YAML 文件，放在 group_vars、host_vars 或 vars_files 里的合并顺序不变，变量覆盖行为与明文文件完全一致。
把口令文件放在仓库里、写进命令行参数（会进 shell 历史与进程列表）或塞进 CI 的明文变量，都等于把 Vault 降级成一层编码。口令文件应为仅所有者可读、由外部密钥管理或运行时注入，并定期轮换。
边界与替代
Vault 保护的是“静态文件里的秘密”，无法阻止拿到口令的人在目标机上读取实际配置，也不做权限分级与审计：它不支持按人授权、按变量授权。需要多人分级、操作留痕、自动轮换的场景，应当把秘密放在专用的密钥管理系统里，再用 Ansible 取用，Vault 只作为没有集中式系统时的过渡方案。