在服务器配置自动化里，密码、API 密钥、数据库口令这类敏感信息一旦以明文写进 playbook，就等于把钥匙挂在门口。Ansible Vault 提供了一套加密机制，让你把敏感变量加密保存，只有持有密码的人才能解密。本文教你如何用 Ansible Vault 管理服务器配置中的敏感信息，从创建加密文件、加密已有变量，到在 playbook 中安全引用，再到团队协作时的密码管理，一步步落地到真实运维场景。无论你管理的是 VPS（虚拟专用服务器，一种通过虚拟化技术划分出的独立计算资源）还是独立服务器，这套方法都能直接套用。
为什么明文密码是运维事故的起点
很多团队把数据库口令、SSH 私钥、第三方 API 密钥直接写进 group_vars 或 playbook 变量里，理由是”内网环境没人看得到”。但真实事故往往来自三个方向：一是代码仓库被误设为公开，或托管平台账号泄露，明文密钥随之暴露；二是离职员工带着仓库克隆权限离开，密码仍然有效；三是日志、CI 输出、错误上报里无意打印出变量值。一旦密钥泄露，攻击者可以直连数据库、接管服务器，而你在日志里往往找不到任何痕迹。
Ansible Vault 解决的是”存储与传输”这一层：敏感变量以 AES-256 加密后落盘，仓库里只保留密文。解密只在 playbook 运行时、由持有密码的节点完成，明文不会进入版本库。这样即使仓库被克隆，攻击者拿到的也只是无法解密的密文。需要说明的是，Vault 保护的是静态存储，不替代 SSH 密钥管理、防火墙等运行时防护，两者是互补关系。
创建加密文件：从零开始
最直接的方式是用 ansible-vault create 新建一个加密文件。执行后命令会提示你设置密码，然后打开编辑器，你写入的内容会以密文保存：
ansible-vault create secrets.yml
文件内容形如：
db_password: "S3cure_P@ssw0rd"
api_key: "sk-live-9f2a..."
保存后，用 cat secrets.yml 看到的是 $ANSIBLE_VAULT;1.1;AES256 开头的密文块，而不是明文。如果你已经有一个明文变量文件，可以用 ansible-vault encrypt 原地加密；反过来，ansible-vault decrypt 用于临时解密查看，操作完记得重新加密。日常查看内容用 ansible-vault view，它只读不解锁编辑器，避免误改。
在 playbook 中安全引用加密变量
加密文件本身不会自动生效，需要在 playbook 或 inventory 里显式引入。常见做法是在 group_vars 目录下放一个加密的 vault.yml，再在普通变量文件里用 !vault 标签引用，或者直接让 playbook 加载加密文件：
- hosts: web
vars_files:
- secrets.yml
tasks:
- name: 写入数据库配置
template:
src: db.conf.j2
dest: /etc/app/db.conf
运行时需要提供密码。单机场景可以用 --ask-vault-pass 交互输入；自动化场景更推荐把密码写入一个权限收紧的本地文件，用 --vault-password-file 指定，避免密码出现在 shell 历史里。如果多个环境使用不同密码，可以用 --vault-id 区分，例如 --vault-id prod@/path/to/prod.pass，让不同环境各用各的密钥，降低单点泄露风险。
加密单个变量与模板中的敏感值
不是所有敏感信息都适合单独建文件。当某个变量只在个别 playbook 里用到，可以用 ansible-vault encrypt_string 只加密这一个值，把密文直接嵌进普通变量文件：
ansible-vault encrypt_string 'S3cure_P@ssw0rd' --name 'db_password'
输出会是一段 db_password: !vault | 开头的密文，你可以把它粘贴到 group_vars/all.yml 里。这样普通变量文件保持可读，只有敏感值以密文存在。模板文件（.j2）里引用变量时，Ansible 会在渲染阶段自动解密，你不需要在模板里做任何特殊处理，只需正常写 {{ db_password }}。这保证了模板本身是明文、可审查，而实际值在运行时才解密。
团队协作与密码轮换
Vault 密码本身是团队共享的秘密，管理不当会变成新的单点。建议把密码放进团队密码管理器（如 Bitwarden、1Password 的共享条目），而不是在聊天工具里明文转发；CI 环境则用平台的 secret 存储注入，避免写死在流水线配置里。当有人离职或怀疑密码泄露时，用 ansible-vault rekey 更换密码，它会把所有加密文件用新密码重新加密，无需逐个解密再加密。
轮换密码时要注意：rekey 只改密码，不改变加密内容本身。如果某个密钥（如数据库口令）本身需要更换，应该先更新加密文件里的值，再重新加密。建议把”密码轮换”纳入定期运维清单，例如每季度执行一次，并配合日志审计确认没有明文密钥被提交进仓库。关于服务器整体安全基线，可以参考我们整理的 服务器安全加固 相关文章，把密钥管理与系统加固放在同一套流程里。
Vault 与明文方案的取舍
有人觉得 Vault 增加了解密步骤，不如直接明文方便。这里用一个对比说明收益：明文方案下，仓库克隆权限等于拿到全部密码，任何有读权限的成员都能看到数据库口令；Vault 方案下，仓库里只有密文，即使仓库被完整克隆，没有密码的人也无法还原敏感值。代价是每次运行 playbook 需要提供密码，以及团队要维护密码本身。对单机、无协作的小项目，明文可能够用；但只要涉及多人协作、多环境或对外暴露仓库，Vault 的收益就明显大于成本。如果你在排查服务器被入侵后的处理流程，可以参考 VPS 入侵应急处理 这篇文章，其中也强调要第一时间轮换所有可能泄露的密钥。
落地建议与下一步
总结一下，把 Ansible Vault 用起来并不复杂：先用 ansible-vault create 建加密文件，把密码、API 密钥放进去；再在 playbook 里用 vars_files 或 !vault 引用；最后把 Vault 密码收进团队密码管理器，并定期 rekey 轮换。建议你从最小的一个 playbook 开始试点，把数据库口令和 API 密钥先加密，跑通后再逐步覆盖更多敏感变量。如果你需要把加密后的配置部署到多台服务器，可以参考 多层缓存架构 中关于配置分发的思路，把敏感信息与普通配置分层管理。对数据库口令这类高频敏感值，还可以结合 MySQL 慢查询分析 的实践，在排查性能的同时确认连接配置没有明文泄露。如果你需要一台能自由配置 root 权限、方便跑 Ansible 的服务器，可以考虑 Hostease 的 VPS 或独立服务器方案，把自动化与密钥管理真正落地到生产环境。