Понимание повышения привилегий

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

• Стать другим пользователем
• Директивы
  • Переменные подключения
  • Опции командной строки
  • Для тех, кто использует Ansible до версии 1.9, sudo и su по-прежнему работают!
  • Ограничения
    • Стать пользователем без привилегий
    • Поддержка плагинов подключения
    • Можно использовать только один метод на хост
    • Нельзя ограничить повышение привилегий определёнными командами
• Стать другим пользователем и сети
  • network_cli и become
  • Установка режима enable для всех задач
    • Пароли для режима enable
  • authorize и auth_pass
• Стать другим пользователем и Windows
  • Права администратора
  • Локальные учётные записи служб
  • Учётные записи без пароля
  • Флаги become
  • Ограничения

Стать другим пользователем

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

Директивы

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

become

устанавливается в yes, чтобы активировать повышение привилегий.

become_user

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

become_method

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

become_flags

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

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

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

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

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

Для выполнения чего-то от имени пользователя nobody при оболочке nologin:

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

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

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

ansible_become

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

ansible_become_method

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

ansible_become_user

установить пользователя, которым вы станете при повышении привилегий; не подразумевает ansible_become: yes

ansible_become_pass

установить пароль повышения привилегий. См. Использование Vault в плейбуках для получения подробностей о том, как избежать использования секретов в открытом виде

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

webserver ansible_user=manager ansible_become=yes

Опции командной строки

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

Для тех, кто использует старые плейбуки, не потребуется ничего изменять, даже несмотря на то, что директивы, переменные и опции 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 удалит временный файл. Если вы доверяете клиентским машинам, проблем не возникнет. Если вы не доверяете клиентским машинам, это потенциальная опасность.

Способы решения проблемы:

• Используйте pipelining. Когда включена конвейерная обработка, Ansible не сохраняет модуль во временный файл на клиенте. Вместо этого он перенаправляет модуль в stdin интерпретатора Python на удалённой машине. Конвейерная обработка не работает для модулей Python, которые предполагают передачу файлов (например: copy, fetch, template), или для модулей, не относящихся к Python.
• (Доступно в Ansible 2.1) Установите поддержку ACL файловой системы POSIX.1e на управляемом хосте. Если временная директория на удалённом хосте смонтирована с поддержкой ACL POSIX и инструмент setfacl находится в удалённой PATH, Ansible будет использовать POSIX ACL для совместного использования файла модуля со вторым пользователем без привилегий, вместо того, чтобы делать файл доступным для всех.
• Не выполняйте действие на удалённой машине, становясь пользователем без привилегий. Временные файлы защищены правами доступа в UNIX, когда вы становитесь become 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 или возможность прямого переключения на него с помощью su (то же самое для pbrun, pfexec или других поддерживаемых методов).

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

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

Become и сети

network_cli и become

Ansible 2.5 добавил поддержку become для перехода в режим enable (режим привилегированного выполнения) на сетевых устройствах, которые его поддерживают. Это заменяет предыдущие опции authorize и auth_pass в provider.

Для использования become для повышения привилегий на сетевых устройствах необходимо установить тип подключения хоста на connection: network_cli. Ansible 2.5.3 поддерживает become для повышения привилегий на eos, ios, и nxos.

Вы можете использовать повышенные привилегии только для конкретных задач, для всего выполнения или для всех выполнений. Добавление become: yes и become_method: enable указывает Ansible на вход в режим enable перед выполнением задачи, выполнения или книги задач.

Если вы видите это сообщение об ошибке, задача, которая его сгенерировала, требует режима enable для успешного выполнения:

Invalid input (privileged mode required)

Чтобы установить режим enable для конкретной задачи, добавьте become на уровне задачи:

- name: Gather facts (eos)
  eos_facts:
    gather_subset:
      - "!hardware"
  become: yes
  become_method: enable

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

- hosts: eos-switches
  become: yes
  become_method: enable
  tasks:
    - name: Gather facts (eos)
      eos_facts:
        gather_subset:
          - "!hardware"

Установка режима enable для всех задач

Часто вы хотите, чтобы все задачи во всех выполнениях выполнялись с использованием режима привилегий. Это лучше всего достигается с помощью group_vars:

group_vars/eos.yml

ansible_connection: network_cli
ansible_network_os: eos
ansible_user: myuser
ansible_become: yes
ansible_become_method: enable

Пароли для режима enable

Если вам нужен пароль для входа в режим enable , вы можете указать его двумя способами:

• указание параметра командной строки --ask-become-pass
• установка переменной подключения ansible_become_pass

authorize и auth_pass

Для подключений HTTPS, которые не могут использовать connection: network_cli, вы можете перейти в режим enable с помощью параметров модуля authorize и auth_pass:

- hosts: eos-switches
  ansible_connection: local
  tasks:
    - name: Gather facts (eos)
      eos_facts:
        gather_subset:
          - "!hardware"
      provider:
        authorize: yes
        auth_pass: " {{ secret_auth_pass }}"

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

Become и Windows

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

Хотя become может быть использован для принятия личности другого пользователя, существуют и другие варианты использования с хостами Windows. Важным вариантом использования является обход некоторых ограничений, накладываемых при работе с WinRM, таких как ограниченное делегирование сети или доступ к запрещённым системным вызовам, таким как API WUA. Вы можете использовать become с тем же пользователем, что и ansible_user для обхода этих ограничений и выполнения команд, которые обычно недоступны в сессии WinRM.

Права администратора

Многие задачи в Windows требуют прав администратора для выполнения. При использовании метода повышения привилегий runas Ansible попытается выполнить модуль с полными правами, доступными удалённому пользователю. Если повышение токена пользователя не удастся, он продолжит использовать ограниченный токен во время выполнения.

До Ansible 2.5, токен мог быть повышен только при отключённом UAC или если удалённый пользователь имел назначенное SeTcbPrivilege. Это ограничение было снято в Ansible 2.5, и пользователь, являющийся членом группы BUILTIN\Administrators, должен иметь повышенный токен во время выполнения модуля.

Для определения типа токена, который Ansible смог получить, выполните следующую задачу и проверьте вывод:

- win_whoami:
  become: yes

В разделе GROUP INFORMATION, запись Mandatory Label определяет, имеет ли пользователь права администратора. Вот метки, которые могут быть возвращены и что они означают:

• Medium: Ansible не смог получить повышенный токен и работал с ограниченным токеном. Только часть привилегий, назначенных пользователю, доступна во время выполнения модуля, и пользователь не имеет прав администратора.
• High: Использовался повышенный токен, и все привилегии, назначенные пользователю, доступны во время выполнения модуля.
• System: Используется учётная запись NT AUTHORITY\System, имеющая максимальный уровень доступных привилегий.

Вывод также покажет список привилегий, предоставленных пользователю. При State==Disabled, привилегии не были включены, но могут быть включены при необходимости. В большинстве случаев эти привилегии автоматически включаются при необходимости.

Если вы используете версию Ansible, более раннюю, чем 2.5, или процесс повышения привилегий runas не удался, повышенный токен можно получить:

• Установите become_user в System, который имеет полный контроль над операционной системой.

• Предоставьте SeTcbPrivilege пользователю, с которым Ansible подключается через WinRM. SeTcbPrivilege - это привилегия высокого уровня, предоставляющая полный контроль над операционной системой. По умолчанию этому праву ни один пользователь не предоставляется, и необходимо соблюдать осторожность при предоставлении этой привилегии пользователю или группе. Для получения дополнительной информации об этой привилегии, см. Выступать частью операционной системы. Вы можете использовать задачу ниже для настройки этого права на хосте Windows:

  - name: grant the ansible user the SeTcbPrivilege right
    win_user_right:
      name: SeTcbPrivilege
      users: '{{ansible_user}}'
      action: add
  

• Отключите UAC на хосте и перезапустите его перед попыткой повышения привилегий пользователя. UAC - это протокол безопасности, разработанный для работы учётных записей с принципом least privilege. Вы можете отключить UAC, выполнив следующие задачи:

  - name: turn UAC off
    win_regedit:
      path: HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
      name: EnableLUA
      data: 0
      type: dword
      state: present
    register: uac_result
  
  - name: reboot after disabling UAC
    win_reboot:
    when: uac_result is changed
  

Локальные учётные записи службы

До версии Ansible 2.5 become работал только с локальными или доменными учётными записями. Локальные учётные записи службы, такие как System или NetworkService, не могли быть использованы как become_user в этих более ранних версиях. Это ограничение было снято в релизе Ansible 2.5. Три учётные записи службы, которые можно установить в become_user:

• System
• NetworkService
• LocalService

Поскольку у локальных учётных записей службы нет паролей, параметр ansible_become_password не требуется и игнорируется при указании.

Учётные записи без пароля

Ansible может быть использован для повышения привилегий до учётной записи без пароля (например, учётной записи Guest). Для повышения привилегий до учётной записи без пароля настройте переменные как обычно, но либо не задавайте ansible_become_pass, либо задайте ansible_become_pass: ''.

Прежде чем become будет работать с такой учётной записью, необходимо отключить локальную политику Учётные записи: Ограничение использования локальных учётных записей без пароля только для входа в консоль. Это можно сделать либо с помощью объекта групповой политики (GPO), либо с помощью этой задачи Ansible:

- name: allow blank password on become
  win_regedit:
    path: HKLM:\SYSTEM\CurrentControlSet\Control\Lsa
    name: LimitBlankPasswordUse
    data: 0
    type: dword
    state: present

Флаги become

Ansible 2.5 добавляет параметр become_flags к методу runas become. Этот параметр можно задать с помощью директивы задачи become_flags или в конфигурации Ansible с помощью ansible_become_flags. Два допустимых значения, которые изначально поддерживаются для этого параметра, это logon_type и logon_flags.

Ключ logon_type устанавливает тип операции входа в систему. Значение может быть установлено в одно из следующих:

• interactive: Тип входа по умолчанию. Процесс будет выполняться в контексте, аналогичном выполнению процесса локально. Это обходит все ограничения WinRM и является рекомендуемым методом.
• batch: Выполняет процесс в контексте пакетной обработки, аналогичном запланированной задаче с установленным паролем. Это должно обойти большинство ограничений WinRM и полезно, если become_user не разрешено входить в систему интерактивно.
• new_credentials: Выполняется с теми же учётными данными, что и вызывающий пользователь, но исходящие подключения выполняются в контексте become_user и become_password, подобно runas.exe /netonly . Флаг logon_flags также должен быть установлен в значение netcredentials_only . Используйте этот флаг, если процессу необходимо получить доступ к сетевому ресурсу (например, к общему ресурсу SMB) с использованием другого набора учётных данных.
• network: Выполняет процесс в сетевом контексте без кэшированных учётных данных. Это приводит к тому же типу сеанса входа в систему, что и при выполнении обычного процесса WinRM без делегирования учётных данных, и действует в соответствии с теми же ограничениями.
• network_cleartext: Подобно типу входа network, но вместо этого кэширует учётные данные, чтобы получить доступ к сетевым ресурсам. Это тот же тип сеанса входа в систему, что и при выполнении обычного процесса WinRM с делегированием учётных данных.

Дополнительную информацию см. в dwLogonType.

Ключ logon_flags указывает, как Windows войдёт в систему пользователя при создании нового процесса. Значение может быть установлено в значение none или в комбинацию следующих:

• with_profile: Установленный по умолчанию флаг входа в систему. Процесс загрузит профиль пользователя из ключа реестра HKEY_USERS в HKEY_CURRENT_USER.
• netcredentials_only: Процесс будет использовать тот же токен, что и вызывающий элемент, но будет использовать become_user и become_password при доступе к удалённому ресурсу. Это полезно в сценариях междоменных взаимодействий, где нет отношений доверия, и должно использоваться с new_credentials logon_type.

По умолчанию logon_flags=with_profile установлено, если профиль не должен загружаться, установите logon_flags=, или если профиль должен загружаться с netcredentials_only, установите logon_flags=with_profile,netcredentials_only.

Дополнительную информацию см. в dwLogonFlags.

Вот несколько примеров использования become_flags с задачами Windows:

- name: copy a file from a fileshare with custom credentials
  win_copy:
    src: \\server\share\data\file.txt
    dest: C:\temp\file.txt
    remote_src: yex
  vars:
    ansible_become: yes
    ansible_become_method: runas
    ansible_become_user: DOMAIN\user
    ansible_become_pass: Password01
    ansible_become_flags: logon_type=new_credentials logon_flags=netcredentials_only

- name: run a command under a batch logon
  win_whoami:
  become: yes
  become_flags: logon_type=batch

- name: run a command and not load the user profile
  win_whomai:
  become: yes
  become_flags: logon_flags=

Ограничения

Следует учитывать следующие ограничения при использовании become в Windows:

• Запуск задачи с async и become в Windows Server 2008, 2008 R2 и Windows 7 не работает.
• По умолчанию пользователь become входит в систему с интерактивным сеансом, поэтому он должен иметь право на это на хосте Windows. Если он не наследует привилегию SeAllowLogOnLocally или наследует привилегию SeDenyLogOnLocally, процесс become завершится с ошибкой. Либо добавьте привилегию, либо установите флаг logon_type для изменения типа входа в систему.
• До версии Ansible 2.3 become работал только тогда, когда ansible_winrm_transport был либо basic, либо credssp. Это ограничение было снято с момента выхода версии 2.4 Ansible для всех хостов, кроме Windows Server 2008 (без версии R2).