ansible 安全防护需构建分层防御机制：严格管控执行权限与连接通道、playbook 层面强制安全约束、实施灰度执行与自动回滚、运行时审计与行为留痕。
Ansible 本身不是攻击工具，但一旦 Playbook 权限失控、配置失当或被恶意篡改，就可能成为“批量攻击的放大器”——比如误删所有服务器的 /etc/shadow、批量关闭防火墙、或向全部节点写入后门账户。防止这类风险，关键不在禁用 Ansible，而在于构建分层防御机制：控制入口、限制动作、隔离影响、留有退路。
严格管控执行权限与连接通道
所有自动化操作必须从可信源头发起，且路径可审计：
- Ansible 控制节点必须部署在专用管理网段，禁止直接暴露外网；SSH 连接只允许通过跳板机或堡垒机中转
- 被管主机的 SSH 配置强制启用 key-only 登录，禁用 PasswordAuthentication 和 PermitRootLogin；使用 ansible_user 指定非 root 的受限系统用户（如 ansible）
- 该受限用户仅通过 sudoers 精确授权必要命令（如 /usr/bin/systemctl restart nginx、/usr/sbin/nft -f /etc/nftables.conf），禁用 NOPASSWD: ALL
- Ansible 配置文件 ansible.cfg 中开启 host_key_checking = True，避免中间人劫持；设置 timeout = 10 防止长连接耗尽资源
Playbook 层面强制安全约束
脚本不是越“全能”越安全，而是越“克制”越可靠：
- 敏感操作一律使用 become: yes 显式声明，并配合 become_user 限定提权目标（如只允许切换到 mysql 用户执行数据库初始化）
- 禁用 shell/command 模块执行任意命令；改用专用模块（如 user、copy、systemd、mysql_user），它们自带参数校验和幂等性保障
- 所有含密码、密钥、token 的变量必须用 ansible-vault 加密；检查 Playbook 是否存在硬编码凭证（grep -r "password:" . / "secret:" .）
- 高危任务（如 reboot、rm、iptables flush）前加 pause 或 assert 校验前提条件，例如确认当前时间不在业务高峰期、目标服务已停止再执行卸载
实施灰度执行与自动回滚
不验证的批量操作等于开盲盒：
- 用 serial: 2 控制并发数，每次只作用于少量节点；结合 limit 参数按业务组（如 web_front、db_slave）分批执行
- 关键 Playbook 必须包含 block + rescue 结构：主流程失败时，自动触发回滚任务（如恢复备份配置、重启原服务、还原旧二进制）
- 每个 copy/template 任务启用 backup: yes，Ansible 自动保存原文件为 .bak；重要目录（如 /etc）变更前可用 shell: find /etc -type f -mtime -1 快速快照
- 部署后调用 uri 或 wait_for 模块探测服务端口、健康接口或关键进程，失败则中断后续节点并告警
运行时审计与行为留痕
让每一次执行都可追溯、可复盘：
- 在 ansible.cfg 中配置 log_path = /var/log/ansible.log，记录所有任务执行时间、主机、模块、参数（注意脱敏敏感字段）
- 启用 ANSIBLE_CALLBACK_WHITELIST=profile_tasks,community.general.log_plays，生成详细耗时分析与操作流水
- 定期扫描 Playbook 仓库，用 ansible-lint 检查常见风险模式（如 command 模块未设 args.changes, no_log: false 泄露密码）
- 将 Playbook 存入 Git，并要求每次提交附带变更说明、影响范围评估和回滚步骤，纳入 CI 流水线做静态检查
