DevOps知识中心
DevOps知识中心

使用 Become 和 Sudo 修复 Ansible 提权错误

在 Ansible 中是否正为“权限拒绝”（permission denied）错误而苦恼？本文将揭示 Ansible 的 `become` 机制及其与 `sudo` 在提权方面的集成方式。学习如何在 `ansible.cfg`、playbooks 和 inventory 中正确配置 `become` 设置，确保您的 `ansible_user` 在目标主机上拥有必需的 `sudo` 权限。探索实用的示例、使用 Ansible Vault 进行安全的密码处理，以及有效的故障排除技巧，以诊断和解决常见的提权问题，确保您的 Ansible playbooks 顺畅且安全地执行。

47 浏览量

使用 Become 和 Sudo 修复 Ansible 权限升级错误

Ansible 是一个强大的自动化引擎，可跨一组服务器简化配置管理、应用程序部署和任务编排。然而，新用户和经验丰富的用户面临的最常见障碍之一是处理权限升级错误。当 Ansible 尝试执行需要提升权限的操作（例如安装软件包、修改系统文件或管理服务）时，这些问题通常会以“权限被拒绝”的错误信息形式出现。

本综合指南将引导您了解 Ansible 的 become 机制的复杂性，它如何与 sudo 集成以进行权限升级，并提供诊断和解决相关身份验证问题的实用步骤。通过理解和正确配置这些设置，您可以确保 Ansible playbook 顺利、安全地执行，无论目标系统的访问要求如何。

理解 Ansible 的 become 机制

从本质上讲，Ansible 通过连接到目标主机（通常是使用 SSH）并以 远程用户 的身份执行命令来工作。然而，许多管理任务需要提升的权限（例如在 Linux 系统上需要 root 访问权限）。这时 Ansible 的 become 功能就派上用场了。become 机制允许 Ansible "成为" 另一个用户，通常是 root，以提升的权限来执行特定的任务或整个剧本（play）。

为什么需要 become

直接以 root 用户身份运行所有 Ansible 任务通常是一种不安全的做法。相反，您通常会以普通、未授权的用户（通常称为 ansible_user）连接到远程主机，然后使用 become 来临时提升执行需要这些权限的任务的权限。这遵循最小权限原则，最大限度地减少安全漏洞的潜在影响。

become 方法

Ansible 支持多种权限升级方法，每种方法都对应不同的系统工具。最常见和最广泛使用的方法，尤其是在 Linux/Unix 系统上，是 sudo（Substitute User Do）。其他方法包括 su、pbrun、doas 等，但本指南主要关注 sudo，因为它应用最广泛。

在 Ansible 中配置 become 设置

Ansible 提供了多种配置 become 设置的方式，从全局配置到特定于任务的覆盖。了解这些作用域对于有效的权限管理至关重要。

1. 在 ansible.cfg 中进行全局配置

对于许多 playbook 的常规用例，您可以在 ansible.cfg 文件中设置默认的 become 参数。该文件通常位于您运行 Ansible 的目录、~/.ansible.cfg 或 /etc/ansible/ansible.cfg 中。

# ansible.cfg
[privilege_escalation]
become=True
become_method=sudo
become_user=root
become_ask_pass=False ; 如果您希望 Ansible 提示输入密码，请设置为 True
  • become=True: 默认启用所有剧本的权限升级。
  • become_method=sudo: 指定 sudo 作为权限升级的方法。
  • become_user=root: 指定要切换成的目标用户为 root。
  • become_ask_pass=False: 控制 Ansible 是否应提示输入 become 密码。如果您没有通过其他方式提供密码，请将其设置为 True。

2. 在 Playbook 中的每个 Play 或任务级别配置

为了实现更精细的控制，可以直接在 playbook 中定义 become 设置，可以在 Play 级别（影响该 Play 中的所有任务）或在单个任务级别。

Play 级别配置：

---
- name: 使用提升的权限安装 Nginx
  hosts: webservers
  become: yes          # 为该 Play 中的所有任务启用 become
  become_user: root
  become_method: sudo

  tasks:
    - name: 确保已安装 Nginx
      ansible.builtin.apt:
        name: nginx
        state: present
      # 此任务将通过 sudo 以 root 身份运行

    - name: 复制 Nginx 配置文件
      ansible.builtin.copy:
        src: nginx.conf
        dest: /etc/nginx/nginx.conf
      # 此任务也将通过 sudo 以 root 身份运行

任务级别配置：

---
- name: 以不同用户管理文件
  hosts: all

  tasks:
    - name: 创建一个由 ansible_user（默认）拥有的文件
      ansible.builtin.file:
        path: /tmp/unprivileged_file.txt
        state: touch
        mode: '0644'

    - name: 创建一个由 root 拥有的文件（使用 become）
      ansible.builtin.file:
        path: /root/privileged_file.txt
        state: touch
        mode: '0600'
      become: yes          # 只有此任务会使用 become
      become_user: root
      become_method: sudo

3. 通过清单变量

become 设置也可以在 Ansible 清单中定义，这允许您为不同的主机或组指定不同的权限升级策略。

hosts.ini 示例：

[webservers]
web1.example.com
web2.example.com

[dbservers]
db1.example.com

[all:vars]
ansible_user=devops_user
ansible_become=true
ansible_become_method=sudo
ansible_become_user=root

这里的 ansible_become、ansible_become_method 和 ansible_become_user 是清单变量，对应于 become 设置。它们可以在 all:vars 级别、组级别或主机级别设置。

4. 使用 ansible-playbook CLI 参数

对于快速覆盖或交互式执行，您可以直接通过命令行传递 become 参数：

  • --become 或 -b: 激活 become。
  • --become-method <METHOD>: 指定 become 方法（例如 sudo）。
  • --become-user <USER>: 指定目标用户（例如 root）。
  • --ask-become-pass 或 -K: 在执行期间提示输入 become 密码。这对于测试很有用，但通常不适用于自动化。

示例：

ansible-playbook my_playbook.yml --become --become-user root --ask-become-pass

确保 become 用户的 sudo 权限

正确配置 Ansible 中的 become 只是完成了一半工作。Ansible 连接所用的用户（ansible_user）必须在目标主机上具有必要的 sudo 权限才能切换到 become_user。这在目标主机上是在 /etc/sudoers 文件或 /etc/sudoers.d/ 下的文件中配置的。

配置 sudoers

sudoers 文件定义了谁可以以谁的身份运行哪些命令。一个常见的条目是允许 Ansible 连接用户（本例中为 devops_user）在不提示密码的情况下以 任何 用户身份运行 任何 命令：

# /etc/sudoers.d/devops
devops_user ALL=(ALL) NOPASSWD: ALL

解释：

  • devops_user: Ansible 连接的用户名（ansible_user）。
  • ALL: 该用户可以从任何终端运行命令。
  • (ALL): 该用户可以以任何用户身份运行命令。
  • NOPASSWD:: 指定对 sudo 操作不需要密码。
  • ALL: 该用户可以运行所有命令。

警告： 授予 NOPASSWD: ALL 会使 ansible_user 在没有密码的情况下获得不受限制的 root 访问权限，这可能带来重大的安全风险。仅在确实需要时才使用此设置，并确保您的 ansible_user 的凭据高度安全。对于更严格的安全措施，您可以指定用户被允许运行的精确命令或命令集。

验证 sudo 访问权限

在运行 playbook 之前，您可以手动验证您的 ansible_user 在目标主机上是否具有 sudo 访问权限。以 ansible_user 身份 SSH 登录到主机并运行：

# 检查您是否可以在不输入密码的情况下 sudo 到 root
sudo -n whoami

# 如果需要密码，系统会提示您。使用简单命令进行测试：
sudo whoami

# 列出当前用户的 sudo 权限：
sudo -l

# 列出特定用户（例如 devops_user）的 sudo 权限：
sudo -l -U devops_user

如果 sudo -n whoami 返回 root 且没有密码提示，则您的 NOPASSWD 配置很可能是正确的。如果提示输入密码，则您的 sudoers 条目可能缺少 NOPASSWD 或配置不正确。

诊断权限升级错误

Ansible 通常会提供信息丰富的错误消息，但与权限相关的问题有时可能很晦涩难懂。以下是一些常见的错误及其解决方案：

1. “permission denied” 或 "