Стать (эскалация привилегий)

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

• Стать
  • Директивы
  • Переменные подключения
  • Параметры командной строки
  • Для тех, кто из версии до 1.9, sudo и su по-прежнему работают!
  • Ограничения
    • Стать непривилегированным пользователем
    • Поддержка плагинов подключения
    • Только один метод может быть включён на хост
    • Нельзя ограничить эскалацию определёнными командами

Стать

Ansible позволяет вам «стать» другим пользователем, отличным от пользователя, который вошёл в систему (удалённый пользователь). Это делается с использованием существующих инструментов эскалации привилегий, которые вы, вероятно, уже используете или настроите, такие как sudo, su, pfexec, doas, pbrun, dzdo, ksu, и другие.

Директивы

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

become

установить в ‘true’/’yes’, чтобы активировать эскалацию привилегий.

become_user

установить в пользователя с необходимыми привилегиями — пользователя, которым вы «становитесь», НЕ пользователя, которым вы заходите в систему. НЕ подразумевает become: yes, чтобы разрешить его установку на уровне хоста.

become_method

(на уровне игры или задачи) переопределяет метод по умолчанию, заданный в ansible.cfg, установить в sudo/su/pbrun/pfexec/doas/dzdo/ksu.

become_flags

(на уровне игры или задачи) позволяют использовать специфические флаги для задач или ролей. Одно из распространённых применений — изменение пользователя на nobody, когда shell установлен на no login. Добавлено в Ansible 2.2.

Например, для управления системной службой (которая требует root привилегий) при подключении как непривилегированного пользователя (это использует тот факт, что значение по умолчанию become_user равно root) :

- name: Ensure the httpd service is running
  service:
    name: httpd
    state: started
  become: true

Чтобы выполнить команду от имени пользователя apache:

- name: Run a command as the apache user
  command: somecommand
  become: true
  become_user: apache

Чтобы сделать что-то от имени пользователя nobody при nologin shell:

- name: Run a command as nobody
  command: somecommand
  become: true
  become_method: su
  become_user: nobody
  become_flags: '-s /bin/sh'

Переменные подключения

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

ansible_become

эквивалентно директиве become, решает, используется ли эскалация привилегий или нет.

ansible_become_method

позволяет установить метод эскалации привилегий

ansible_become_user

позволяет установить пользователя, которым вы становитесь через эскалацию привилегий, не подразумевает ansible_become: True

ansible_become_pass

позволяет установить пароль для эскалации привилегий

Например, если вы хотите выполнить все задачи от имени root на сервере с именем webserver, но можете подключиться только как пользователь manager, вы можете использовать запись в инвентаре, как это:

webserver ansible_user=manager ansible_become=true

Параметры командной строки

Для тех, кто из версии до 1.9, sudo и su по-прежнему работают!

Для тех, кто использует старые playbook'ы, не нужно ничего менять, даже если они устарели, директивы, переменные и опции sudo и su по-прежнему будут работать. Рекомендуется перейти на become, так как они могут быть удалены в будущем. Вы не можете смешивать директивы на одном объекте (become и sudo), Ansible будет жаловаться, если вы попробуете.

Become по умолчанию будет использовать старые конфигурации и переменные sudo/su, если они существуют, но переопределит их, если вы укажете какие-либо новые.

Ограничения

Хотя эскалация привилегий в основном интуитивна, существуют некоторые ограничения в её работе. Пользователи должны знать об этом, чтобы избежать неожиданностей.

Стать непривилегированным пользователем

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

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

Проблема возникает, когда become_user является непривилегированным пользователем. Ansible 2.0.x и ниже делают файл модуля доступным для чтения всем в этом случае, так как файл модуля записывается как пользователь, от имени которого Ansible подключается, но файл должен быть доступен для чтения пользователю, для которого Ansible установлен в become.

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

Способы решения этой проблемы включают:

• Используйте потоки. При включении потоков Ansible не сохраняет модуль во временный файл на клиенте. Вместо этого он передает модуль в стандартный ввод интерпретатора Python на удалённой машине. Потоки не работают для модулей, не являющихся Python.
• (Доступно в Ansible 2.1) Установите поддержку POSIX.1e файловых ACL на управляемом хосте. Если временная директория на удалённом хосте смонтирована с поддержкой POSIX ACL и инструмент setfacl находится в удалённой PATH , Ansible будет использовать POSIX ACL для совместного использования файла модуля со вторым непривилегированным пользователем вместо того, чтобы делать файл доступным для чтения для всех.
• Не выполняйте действие на удалённой машине, становясь непривилегированным пользователем. Временные файлы защищены правами доступа UNIX, когда вы становитесь root или не используете become. В Ansible 2.1 и выше права доступа UNIX также безопасны, если вы подключаетесь к управляемой машине как root, а затем используете become к непривилегированной учётной записи.

В дополнение к дополнительным способам безопасного выполнения этого действия, Ansible 2.1 также усложняет случайное выполнение небезопасного действия. В Ansible 2.0.x и ниже Ansible молча позволит небезопасному поведению, если он не сможет найти другой способ поделиться файлами с непривилегированным пользователем, в Ansible 2.1 и выше Ansible по умолчанию выдаёт ошибку, если он не может сделать это безопасно. Если вы не можете внести какие-либо изменения, чтобы решить проблему, и решите, что машина, на которой вы работаете, достаточно безопасна, чтобы модули, которые вы хотите запустить там, были доступны для чтения всем, вы можете включить allow_world_readable_tmpfiles в файл ansible.cfg. Установка allow_world_readable_tmpfiles изменит это с ошибки на предупреждение и позволит задаче выполняться, как и до версии 2.1.

Поддержка плагинов подключения

Методы эскалации привилегий также должны поддерживаться используемым плагином подключения. Большинство плагинов подключения выдадут предупреждение, если они не поддерживают become. Некоторые просто проигнорируют его, так как они всегда выполняются как root (тюрьма, chroot и т.д.).

Только один метод может быть включён на хост

Методы нельзя объединять в цепочку. Вы не можете использовать sudo /bin/su - для получения прав пользователя, вам необходимо обладать привилегиями для выполнения команды от имени этого пользователя в sudo или иметь возможность напрямую переключиться на него (то же самое для pbrun, pfexec или других поддерживаемых методов).

Нельзя ограничить повышение привилегий определёнными командами

Разрешения на повышение привилегий должны быть общими. Ansible не всегда использует конкретную команду для выполнения действия, но запускает модули (код) из временного файла с именем, которое меняется каждый раз. Если у вас разрешены команды «/sbin/service» или «/bin/chmod», это приведёт к ошибке с ansible, так как эти пути не будут совпадать с временным файлом, который ansible создаёт для запуска модуля.