Исправление ошибок повышения привилегий Ansible с помощью Become и Sudo

Ошибки повышения привилегий Ansible обычно возникают, когда задаче требуется root-доступ, но ваш пользователь подключения не может правильно использовать sudo. Вы можете увидеть «отказано в доступе», «отсутствует пароль sudo» или задачу, которая работает через SSH, но не выполняется внутри плейбука.

Исправление обычно представляет собой комбинацию настроек become Ansible и конфигурации sudoers на целевом хосте. Это руководство показывает обе стороны.

Понимание механизма become Ansible

По своей сути Ansible подключается к целевым хостам, обычно через SSH, и выполняет команды от имени удаленного пользователя. Однако многие административные задачи требуют повышенных привилегий (например, root-доступ в Linux-системах). Здесь вступает в игру функция become Ansible. Механизм become позволяет Ansible «стать» другим пользователем, обычно root, для выполнения определенных задач или целых плейбуков с повышенными разрешениями.

Почему become необходим

Запуск всех задач Ansible напрямую от пользователя root — это, как правило, плохая практика безопасности. Вместо этого вы обычно подключаетесь к удаленным хостам как обычный непривилегированный пользователь (часто называемый ansible_user), а затем используете become для временного повышения привилегий для задач, которые в этом нуждаются. Это соответствует принципу минимальных привилегий, минимизируя потенциальное влияние нарушения безопасности.

Методы become

Ansible поддерживает несколько методов повышения привилегий, каждый из которых соответствует различным системным утилитам. Наиболее распространенным и широко используемым методом, особенно в Linux/Unix-системах, является sudo (Substitute User Do). Другие методы включают su, pbrun, doas и другие, но это руководство будет в основном сосредоточено на sudo из-за его распространенности.

Настройка параметров become в Ansible

Ansible предлагает несколько способов настройки параметров become, от глобальных конфигураций до переопределений на уровне задач. Понимание этих областей действия имеет решающее значение для эффективного управления привилегиями.

1. Глобальная конфигурация в ansible.cfg

Для общих случаев использования в нескольких плейбуках вы можете установить параметры become по умолчанию в вашем файле ansible.cfg. Обычно он находится в каталоге, где вы запускаете Ansible, ~/.ansible.cfg или /etc/ansible/ansible.cfg.

# ansible.cfg
[privilege_escalation]
become=True
become_method=sudo
become_user=root
become_ask_pass=False ; Установите True, если хотите, чтобы Ansible запрашивал пароль

• become=True: Включает повышение привилегий по умолчанию для всех плейбуков.
• become_method=sudo: Указывает sudo как метод повышения привилегий.
• become_user=root: Указывает root как целевого пользователя, которым нужно стать.
• become_ask_pass=False: Управляет тем, должен ли Ansible запрашивать пароль become. Установите True, если вы не предоставляете пароль другими способами.

2. На уровне плейбука или задачи в плейбуках

Для более детального контроля параметры become могут быть определены непосредственно в ваших плейбуках, либо на уровне плейбука (влияет на все задачи в этом плейбуке), либо на уровне отдельной задачи.

Конфигурация на уровне плейбука:

---
- name: Установка Nginx с повышенными привилегиями
  hosts: webservers
  become: yes          # Включить become для всех задач в этом плейбуке
  become_user: root
  become_method: sudo

  tasks:
    - name: Убедиться, что Nginx установлен
      ansible.builtin.apt:
        name: nginx
        state: present
      # Эта задача будет выполнена от root через sudo

    - name: Копирование конфигурации Nginx
      ansible.builtin.copy:
        src: nginx.conf
        dest: /etc/nginx/nginx.conf
      # Эта задача также будет выполнена от root через sudo

Конфигурация на уровне задачи:

---
- 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. Использование аргументов CLI ansible-playbook

Для быстрых переопределений или интерактивного выполнения вы можете передать параметры become непосредственно через командную строку:

• --become или -b: Активирует become.
• --become-method <МЕТОД>: Указывает метод become (например, sudo).
• --become-user <ПОЛЬЗОВАТЕЛЬ>: Указывает целевого пользователя (например, root).
• --ask-become-pass или -K: Запрашивает пароль become во время выполнения. Это полезно для тестирования, но обычно не для автоматизации.

Пример:

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

Обеспечение прав sudo для пользователя become

Правильная настройка become в Ansible — это только половина дела. Пользователь, от имени которого 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

Перед запуском плейбука вы можете вручную проверить, есть ли у вашего ansible_user доступ sudo на целевом хосте. Подключитесь по SSH к хосту как ansible_user и выполните:

# Проверьте, можете ли вы выполнить sudo до root без пароля
sudo -n whoami

# Если требуется пароль, будет предложено его ввести. Проверьте простой командой:
sudo whoami

# Список привилегий sudo для текущего пользователя:
sudo -l

# Список привилегий sudo для конкретного пользователя (например, devops_user):
sudo -l -U devops_user

Если sudo -n whoami возвращает root без запроса пароля, ваша конфигурация NOPASSWD, вероятно, верна. Если он запрашивает пароль, ваша запись sudoers может не содержать NOPASSWD или настроена неправильно.

Диагностика ошибок повышения привилегий

Ansible обычно предоставляет информативные сообщения об ошибках, но проблемы, связанные с привилегиями, иногда могут быть загадочными. Вот распространенные ошибки и их решения:

1. «Отказано в доступе»

Это обычно означает, что задача была выполнена от имени непривилегированного пользователя подключения вместо root.

Проверьте плейбук или задачу:

- name: Установка пакета, требующего root
  ansible.builtin.package:
    name: nginx
    state: present
  become: true

Затем подтвердите, какого пользователя использует Ansible:

ansible webservers -m ansible.builtin.command -a 'whoami'
ansible webservers -b -m ansible.builtin.command -a 'whoami'

Вторая команда должна вернуть root, если sudo работает.

2. «Отсутствует пароль sudo»

Это происходит, когда целевой хост требует пароль sudo, но Ansible его не предоставил.

Для интерактивного запуска используйте:

ansible-playbook site.yml --ask-become-pass

Для автоматизации избегайте хранения паролей в открытом виде в инвентаре. Используйте Ansible Vault для ansible_become_password, если в вашей среде не разрешен sudo без пароля.

ansible-vault encrypt group_vars/webservers/vault.yml

Пример имени зашифрованной переменной перед шифрованием:

ansible_become_password: "заменить-на-реальный-пароль"

3. «Пользователь отсутствует в файле sudoers»

Это проблема конфигурации целевого хоста. Ansible не может это исправить, если он уже не может подключиться от имени пользователя с достаточными привилегиями.

На целевом хосте используйте visudo или файл в /etc/sudoers.d/:

devops_user ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/apt, /usr/bin/yum

Это уже, чем NOPASSWD: ALL, но работает только в том случае, если вашим плейбукам нужны именно эти команды. Модули пакетов могут вызывать разные двоичные файлы в зависимости от ОС, поэтому тестируйте тщательно.

4. Неправильный become_user

Для большинства задач администрирования Linux используется become_user: root. Если вы установите become_user для учетной записи приложения, этот пользователь все равно может не иметь разрешения на изменение системных файлов или управление службами.

Используйте быструю проверку:

- name: Подтверждение эффективного пользователя
  ansible.builtin.command: whoami
  become: true
  changed_when: false

Если вывод не соответствует ожидаемому пользователю, проверьте переменные плейбука, переменные инвентаря и ansible.cfg на наличие конфликтующих значений become_user.

Безопасный контрольный список устранения неполадок

Работайте от целевого хоста обратно к плейбуку:

1. Подключитесь по SSH к хосту как ansible_user.
2. Выполните sudo -l и подтвердите, что у пользователя есть необходимые права.
3. Выполните sudo -n whoami, если вы ожидаете sudo без пароля.
4. Выполните ansible all -b -m command -a 'whoami' для одного тестового хоста.
5. Добавьте -vvv к запуску проблемного плейбука, если ошибка все еще неясна.

Ключевой вывод

Ansible become только говорит Ansible повысить привилегии. Целевой хост все равно должен разрешить пользователю подключения сделать это через sudo или другой метод become. Исправьте обе стороны: установите become там, где это требуется задаче, затем проверьте права sudo непосредственно на хосте.