Ansible权限控制的核心是“最小化授权+显式声明+分离敏感信息”。需按角色分组设定become策略，禁用硬编码密码，优选ansible-vault加密，结合Jumpserver实现审计隔离，并关闭危险默认配置如host_key_checking和全局become。
Ansible 批量执行命令时，权限控制不是附加功能，而是安全底线。不加约束的 become（提权）操作可能让一个误配的 playbook 变成全网风险点——比如用 root 权限删错目录、改错配置，或暴露密码到日志里。真正有效的权限控制，核心在于“最小化授权 + 显式声明 + 分离敏感信息”，而不是单纯依赖 sudo 密码是否填对。
明确提权方式与适用场景
Ansible 支持多种 become_method（提权方法），选错会导致失败或绕过审计：
-
sudo：最常用，默认行为；需目标主机上用户已配置免密 sudo 权限（如
%wheel ALL=(ALL) NOPASSWD: ALL）；适合日常运维任务 -
su：需提供目标用户的密码（通过
ansible_become_pass或 vault 加密）；适用于禁用 sudo、仅开放 su 的老旧系统 - dzdo：国产堡垒机（如 Jumpserver）常用替代 sudo 的特权代理命令；需提前在目标主机安装并配置好 dzdo 规则
- runas：Windows 场景专用；Linux 下无效
注意：不要在 playbook 中硬编码密码。例如，避免写 become_pass: "123456"，而应通过 ansible-vault 加密变量文件，或由外部传入（-e "@vaulted_vars.yml"）。
按角色分组控制提权粒度
不同业务线、不同环境（生产/测试）应使用不同提权策略，不能“一刀切”：
- 在 inventory 文件中为不同主机组定义专属变量，例如：
[prod_servers]
10.1.10.100 ansible_become=yes ansible_become_method=sudo ansible_become_user=root
[app_nodes]
10.1.20.50 ansible_become=yes ansible_become_method=sudo ansible_become_user=appuser
- Playbook 中用
become_user指定具体目标用户，而非一律提权到 root；例如部署 Java 应用时，用become_user: appuser启动服务，比用 root 更符合最小权限原则 - 对数据库节点等高敏资产，可禁用全局 become，在特定 task 中显式启用，并限定只允许执行白名单命令（如
systemctl restart mysqld）
结合 Jumpserver 等堡垒机强化审计与隔离
直接 SSH 到服务器执行 Ansible 存在跳过审计的风险。接入 Jumpserver 后，批量命令实际经由堡垒机代理，天然具备操作留痕、会话录像、IP 白名单等能力：
- 配置 Ansible 使用 Jumpserver 作为跳转代理（ProxyJump），inventory 中设置：
ansible_ssh_common_args="-o ProxyJump=jumpuser@jumpserver.example.com" - 在 Jumpserver 中为 Ansible 运维账号分配精确的资产授权（而非“所有主机”），并绑定命令策略（如禁止
rm -rf /、dd if=等高危命令） - 启用 Jumpserver 的命令审批流程，关键环境的提权操作需二次人工确认，避免自动化误操作扩散
禁用危险默认行为，加固基础配置
很多安全问题源于未修改的 Ansible 默认值：
- 关闭 SSH 主机密钥检查（
host_key_checking = False）虽方便，但易受中间人攻击；应在首次连接后固定 known_hosts，或启用ansible_ssh_host_key_checking = True - 禁用密码登录（
PasswordAuthentication no）必须在启用密钥登录验证成功后再执行，Ansible 可用 playbook 自动完成该切换 - 避免在
~/.ansible.cfg中全局开启become = true；提权必须在每个需要的 task 或 play 中显式声明 - 对敏感任务（如密码重置、证书更新），强制要求使用
check_mode: no并配合vars_prompt交互确认，防止静默执行
