Ansible Vault加密非YAML文件的正确解密及内容使用方法咨询

方案问题定位与合规性说明 #

!vault报错原因 #

!vault标签仅适用于标记单条加密的字符串变量值，你通过ansible-vault create生成的是完整的独立加密文件，而非加密的变量值。lookup('file')读取该文件时，Ansible控制节点已经自动完成解密，返回的是明文内容，此时给明文变量加!vault标签，Ansible会尝试将明文当作加密串二次解密，自然触发input is not vault encrypted data报错。

现有方案的解密时机与风险 #

当前方案的解密时机是控制节点执行lookup的变量解析阶段，解密逻辑本身没有问题，但存在明显的敏感数据泄露风险：

• 解密后的明文密钥会暂存在Ansible运行时变量池中，如果在任意位置打印该变量、或开启了facts持久化缓存，明文会直接泄露到控制台、日志或磁盘文件
• 你仅在copy任务中配置了no_log: true，只能规避该任务的执行日志泄露，无法覆盖变量全生命周期的风险点

更规范的实现方式 #

根据使用场景可选两种最优实践：

场景1：单个小体积敏感数据（推荐） #

直接加密单条变量值，不需要单独维护加密文件：

1. 执行命令生成加密变量：
   ansible-vault encrypt_string '你的密钥明文' --name 'my_key'
2. 将输出的自带!vault标签的加密串直接写入变量文件即可
3. 任务调用时直接引用变量，Ansible会在变量被使用时自动解密，全程不会出现明文落地的问题

场景2：必须保留独立加密密钥文件 #

不要通过lookup读取文件存变量，直接用copy模块的src参数传入加密文件路径，Ansible会自动在控制节点解密后传输到远程，不会把明文存入运行时变量：

- name: Create My Private Key
  ansible.builtin.copy:
    src: "{{ inventory_dir }}/group_vars/my.key"
    dest: "{{ secrets_key }}"
    mode: '0600'
    no_log: true

额外安全建议 #

• 可在ansible.cfg中全局开启no_log = true，仅非敏感任务按需关闭该配置，避免意外日志泄露
• 生产环境执行playbook不要加-v/-vvv等调试参数，调试模式会绕过no_log限制输出敏感数据

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