Chef推送配置文件时如何加密密码或通过Ruby块修改内容

方案1：cookbook files目录存密码+手动加密文件 #

• 常规手动加密文件的实现方式不可行：你在本地把带密码的配置文件加密后放到files目录，推送到Linux实例后必须解密才能被业务服务正常读取，不管你把解密密钥硬写在recipe逻辑里、还是放在cookbook的其他目录下，只要能拿到cookbook的人就能顺藤摸瓜拿到密钥还原明文密码，这种手动加密完全是防君子不防小人，没有实际安全意义。
• 如果要走cookbook托管配置文件的路径，不要自己做文件加密，直接用Chef原生的敏感数据存储能力存密码：把密码这类敏感字段单独存在加密数据包或者Chef Vault里，配置文件本身只保留非敏感的基础配置，推送配置时动态拉取敏感值填充进去，cookbook本身不会留存明文密码，密钥单独做权限管控，这才是生产可用的实现方式。你当前已经在用的remote_directory资源不需要废弃，只需要调整逻辑，在目录同步完成后做敏感字段填充即可。

方案2：通过ruby_block动态调整文件内容 #

• 这个方案可行，但要避开硬编码的坑：绝对不要把密码明文直接写在ruby_block的代码逻辑里，不然只是把明文密码从配置文件挪到了recipe代码里，还是会有泄露风险。正确的实现步骤如下：
  1. 先配置remote_directory资源同步不含敏感密码的基础配置目录，给资源设置action :nothing，避免资源自动执行时提前把空密码配置同步完被服务加载
  2. ruby_block逻辑中先拉取存在加密存储里的密码值，再读取已经同步到节点目标路径的配置文件，把空密码变量替换为实际值后写回文件，写回后记得把配置文件权限设置为0600，属主对齐业务服务的运行用户，避免节点上其他非授权本地用户读取到密码内容
  3. 内容写入完成后，触发remote_directory资源的通知动作，按需重启对应业务服务加载新配置
• 注意要排好Chef资源的执行顺序：先同步基础目录文件，再执行ruby_block修改内容，最后触发服务重载，避免出现服务先读到空密码配置启动失败的问题。

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