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

Директивы become

Директивы, управляющие become, можно задавать на уровне play или задачи. Их можно переопределить, задав переменные подключения, которые часто различаются для разных узлов. Эти переменные и директивы независимы. Например, задание become_user не задаёт become.

become

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

become_user

задайте пользователя с нужными привилегиями — пользователя, которым вы become, А НЕ пользователя, под которым вы входите в систему. НЕ подразумевает become: true, что позволяет задавать его на уровне узла. Значение по умолчанию — root.

become_method

(на уровне play или задачи) переопределяет метод по умолчанию, заданный в ansible.cfg; задайте для использования любого из плагинов Become.

become_flags

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

Например, чтобы управлять системной службой (для чего нужны привилегии root), подключившись как пользователь без привилегий 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:

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

Чтобы указать пароль для sudo, запустите ansible-playbook с параметром --ask-become-pass (сокращённо -K). Если вы запускаете плейбук, использующий become, и он, похоже, завис, скорее всего, он остановился на запросе повышения привилегий. Остановите его с помощью CTRL-c, а затем выполните плейбук с параметром -K и соответствующим паролем.

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

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

ansible_become

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

ansible_become_method

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

ansible_become_user

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

ansible_become_password

задаёт пароль для повышения привилегий. Сведения о том, как не хранить секреты в открытом виде, см. в разделе Использование зашифрованных переменных и файлов

ansible_common_remote_group

определяет, следует ли Ansible попытаться chgrp временные файлы в группу, если оба способа — setfacl и chown — завершились неудачей. Дополнительные сведения см. в разделе Риски перехода к непривилегированному пользователю. Добавлено в версии 2.10.

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

webserver ansible_user=manager ansible_become=true

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

--ask-become-pass, -K

запросить пароль для повышения привилегий; не подразумевает использование become. Обратите внимание: этот пароль будет использоваться для всех узлов.

--become, -b

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

--become-method=BECOME_METHOD

используемый метод повышения привилегий (по умолчанию=sudo), допустимые значения: [ sudo | su | pbrun | pfexec | doas | dzdo | ksu | runas | machinectl ]

--become-user=BECOME_USER

выполнять операции от имени этого пользователя (по умолчанию=root), не подразумевает --become/-b

Риски перехода к непривилегированному пользователю

Модули Ansible выполняются на удалённой машине: сначала параметры подставляются в файл модуля, затем файл копируется на удалённую машину и, наконец, выполняется там.

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

Однако, если и пользователь подключения, и become_user являются непривилегированными, файл модуля записывается от имени пользователя, под которым Ansible подключается (remote_user), но файл должен быть доступен для чтения пользователю, от имени которого Ansible настроен become. Способ решения этой проблемы Ansible может различаться в зависимости от платформы. В системах POSIX Ansible решает её следующим образом:

Сначала, если setfacl установлен и доступен в удалённом PATH, а временный каталог на удалённом узле смонтирован с поддержкой списков управления доступом файловой системы POSIX.1e, Ansible использует списки ACL POSIX, чтобы предоставить второму непривилегированному пользователю доступ к файлу модуля.

Затем, если списки ACL POSIX недоступны или не удалось выполнить setfacl, Ansible попытается изменить владельца файла модуля с помощью chown в системах, поддерживающих такую операцию для непривилегированного пользователя.

Начиная с Ansible 2.11, на этом этапе Ansible попробует выполнить chmod +a — специфичный для macOS способ задания списков ACL для файлов.

Начиная с Ansible 2.10, если все описанные выше способы не сработали, Ansible проверит значение параметра конфигурации ansible_common_remote_group. Во многих системах пользователь может изменить групповое владение файла на группу, в которую он входит. Поэтому, если у второго непривилегированного пользователя (become_user) есть общая группа UNIX с пользователем, от имени которого подключён Ansible (remote_user), и если для ansible_common_remote_group указана эта группа, Ansible может попытаться изменить групповое владение файлом модуля на эту группу с помощью chgrp, благодаря чему become_user, скорее всего, сможет прочитать файл.

На этом этапе, если задано ansible_common_remote_group и попытка выполнить chgrp завершилась успешно, Ansible предполагает (но, что важно, не проверяет), что нового группового владения достаточно, и не переходит к следующим способам. То есть Ansible не проверяет, действительно ли become_user состоит в одной группе с remote_user; если команда завершилась успешно, Ansible считает операцию успешной и не переходит к проверке world_readable_temp, описанной ниже.

Если ansible_common_remote_group не задан и описанная выше попытка chown завершилась неудачей либо если ansible_common_remote_group задан, но команда chgrp (или последующая команда chmod для установки разрешений группы) завершилась с ошибкой, Ansible в последнюю очередь проверит параметр world_readable_temp. Если он включён, Ansible поместит файл модуля во временный каталог с разрешениями на чтение для всех пользователей, чтобы become_user (а также любой другой пользователь системы) мог прочитать содержимое файла. Если какие-либо параметры, передаваемые модулю, содержат конфиденциальные данные и вы не доверяете удалённым машинам, это может представлять угрозу безопасности.

После завершения работы модуля Ansible удаляет временный файл.

Полностью избежать описанной последовательности действий можно несколькими способами:

• Используйте pipelining. При включённой передаче через конвейер Ansible не сохраняет модуль во временный файл на клиенте. Вместо этого он передаёт модуль через стандартный ввод удалённому интерпретатору Python. Передача через конвейер не работает для модулей Python, выполняющих передачу файлов (например, copy, fetch, template), а также для модулей, не написанных на Python.
• Не переходите к непривилегированному пользователю. Если вы become root или не используете become, временные файлы защищены разрешениями UNIX. В Ansible 2.1 и более поздних версиях разрешения файлов UNIX также обеспечивают безопасность, если вы подключаетесь к управляемой машине как root, а затем используете become для доступа к непривилегированной учётной записи.

Ansible затрудняет незаметное небезопасное использование become. Начиная с Ansible 2.1, Ansible по умолчанию выдаёт ошибку, если не может безопасно выполнить become. Если вы не можете использовать передачу через конвейер или списки ACL POSIX, вынуждены подключаться как непривилегированный пользователь и использовать become для выполнения действий от имени другого непривилегированного пользователя, а также считаете управляемые узлы достаточно безопасными для предоставления всем пользователям доступа на чтение к выполняемым на них модулям, можно включить параметр world_readable_temp. Тогда ошибка будет заменена предупреждением, и задача сможет выполниться так же, как до версии 2.1.

В Ansible 2.10 появился описанный выше резервный вариант с ansible_common_remote_group. Как упоминалось выше, если он включён, он используется, когда remote_user и become_user являются непривилегированными пользователями. Подробные сведения об условиях использования этого резервного варианта приведены выше.

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

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

Для каждого узла можно включить только один метод

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

Повышение привилегий должно быть универсальным

Нельзя ограничить разрешения на повышение привилегий определёнными командами. Ansible не всегда использует для выполнения действий конкретную команду, а запускает модули (код) из временного файла, имя которого каждый раз меняется. Если в список разрешённых команд входят «/sbin/service» или «/bin/chmod», выполнение в Ansible завершится ошибкой, поскольку эти пути не совпадут с временным файлом, который Ansible создаёт для запуска модуля. Если правила безопасности ограничивают среду sudo/pbrun/doas запуском только определённых путей команд, используйте Ansible из специальной учётной записи, на которую это ограничение не распространяется, либо используйте AWX или Red Hat Ansible Automation Platform для управления непрямым доступом к учётным данным SSH.

Возможен недоступ к переменным среды, задаваемым pamd_systemd

В большинстве дистрибутивов Linux, использующих systemd в качестве системы инициализации, методы, используемые become по умолчанию, не открывают новый «сеанс» в смысле systemd. Поскольку модуль pam_systemd не полностью инициализирует новый сеанс, результат может отличаться от обычного сеанса, открытого через ssh: некоторые переменные среды, задаваемые pam_systemd, в частности XDG_RUNTIME_DIR, не устанавливаются для нового пользователя, а наследуются или просто очищаются.

Это может вызвать проблемы при попытке вызвать команды systemd, которым для доступа к шине требуется XDG_RUNTIME_DIR:

$ echo $XDG_RUNTIME_DIR

$ systemctl --user status
Failed to connect to bus: Permission denied

Чтобы заставить become открыть новый сеанс systemd через pam_systemd, можно использовать become_method: machinectl.

Дополнительные сведения см. в этом обсуждении systemd.

Устранение ошибок временных файлов

• Не удалось задать разрешения для временных файлов, которые Ansible необходимо создать при переходе к непривилегированному пользователю»
• Эту ошибку можно устранить, установив пакет, содержащий команду setfacl. (Часто это пакет acl, но сверьтесь с документацией своей ОС.)

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

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

group_vars/eos.yml

ansible_connection: ansible.netcommon.network_cli
ansible_network_os: arista.eos.eos
ansible_user: myuser
ansible_become: true
ansible_become_method: enable

authorize и auth_pass

Ansible по-прежнему поддерживает режим enable с помощью connection: local для старых плейбуков сетевых устройств. Чтобы перейти в режим enable с помощью connection: local, используйте параметры модуля authorize и auth_pass:

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

Рекомендуем обновить плейбуки и последовательно использовать become для режима enable на сетевых устройствах. Использование словарей authorize и provider будет объявлено устаревшим в будущем. Подробные сведения см. в документации Параметры платформ.

Административные права

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

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

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

- name: Check my username
  ansible.windows.win_whoami:
  become: true

Вывод будет выглядеть примерно так:

ok: [windows] => {
    "account": {
        "account_name": "vagrant-domain",
        "domain_name": "DOMAIN",
        "sid": "S-1-5-21-3088887838-4058132883-1884671576-1105",
        "type": "User"
    },
    "authentication_package": "Kerberos",
    "changed": false,
    "dns_domain_name": "DOMAIN.LOCAL",
    "groups": [
        {
            "account_name": "Administrators",
            "attributes": [
                "Mandatory",
                "Enabled by default",
                "Enabled",
                "Owner"
            ],
            "domain_name": "BUILTIN",
            "sid": "S-1-5-32-544",
            "type": "Alias"
        },
        {
            "account_name": "INTERACTIVE",
            "attributes": [
                "Mandatory",
                "Enabled by default",
                "Enabled"
            ],
            "domain_name": "NT AUTHORITY",
            "sid": "S-1-5-4",
            "type": "WellKnownGroup"
        },
    ],
    "impersonation_level": "SecurityAnonymous",
    "label": {
        "account_name": "High Mandatory Level",
        "domain_name": "Mandatory Label",
        "sid": "S-1-16-12288",
        "type": "Label"
    },
    "login_domain": "DOMAIN",
    "login_time": "2018-11-18T20:35:01.9696884+00:00",
    "logon_id": 114196830,
    "logon_server": "DC01",
    "logon_type": "Interactive",
    "privileges": {
        "SeBackupPrivilege": "disabled",
        "SeChangeNotifyPrivilege": "enabled-by-default",
        "SeCreateGlobalPrivilege": "enabled-by-default",
        "SeCreatePagefilePrivilege": "disabled",
        "SeCreateSymbolicLinkPrivilege": "disabled",
        "SeDebugPrivilege": "enabled",
        "SeDelegateSessionUserImpersonatePrivilege": "disabled",
        "SeImpersonatePrivilege": "enabled-by-default",
        "SeIncreaseBasePriorityPrivilege": "disabled",
        "SeIncreaseQuotaPrivilege": "disabled",
        "SeIncreaseWorkingSetPrivilege": "disabled",
        "SeLoadDriverPrivilege": "disabled",
        "SeManageVolumePrivilege": "disabled",
        "SeProfileSingleProcessPrivilege": "disabled",
        "SeRemoteShutdownPrivilege": "disabled",
        "SeRestorePrivilege": "disabled",
        "SeSecurityPrivilege": "disabled",
        "SeShutdownPrivilege": "disabled",
        "SeSystemEnvironmentPrivilege": "disabled",
        "SeSystemProfilePrivilege": "disabled",
        "SeSystemtimePrivilege": "disabled",
        "SeTakeOwnershipPrivilege": "disabled",
        "SeTimeZonePrivilege": "disabled",
        "SeUndockPrivilege": "disabled"
    },
    "rights": [
        "SeNetworkLogonRight",
        "SeBatchLogonRight",
        "SeInteractiveLogonRight",
        "SeRemoteInteractiveLogonRight"
    ],
    "token_type": "TokenPrimary",
    "upn": "vagrant-domain@DOMAIN.LOCAL",
    "user_flags": []
}

В разделе label запись account_name указывает, есть ли у пользователя права администратора. Ниже приведены возможные значения и их обозначения:

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

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

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

• Задайте для become_user значение System, которому предоставлен полный контроль над операционной системой.

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

  - name: grant the ansible user the SeTcbPrivilege right
    ansible.windows.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 работал в Windows только с локальной учетной записью или учетной записью домена. Локальные служебные учетные записи, такие как System или NetworkService, нельзя было использовать в качестве become_user в этих старых версиях. Это ограничение было снято в Ansible 2.5. В качестве значения become_user можно указать одну из трех служебных учетных записей:

• System
• NetworkService
• LocalService

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

Become без указания пароля

Начиная с Ansible 2.8, become можно использовать для перехода к локальной учетной записи Windows или учетной записи домена без пароля. Для работы этого метода должны выполняться следующие требования:

• Учетной записи для подключения назначена привилегия SeDebugPrivilege
• Учетная запись для подключения входит в группу BUILTIN\Administrators
• Для become_user назначено право пользователя SeBatchLogonRight или SeNetworkLogonRight

Become без пароля выполняется одним из двух способов:

• Создание копии токена существующего сеанса входа, если учетная запись уже вошла в систему
• Использование S4U для создания токена входа, действительного только на удаленном узле

В первом случае процесс become запускается из другого сеанса входа этой учетной записи. Это может быть существующий сеанс RDP или вход в систему через консоль, однако так происходит не всегда. Этот вариант аналогичен параметру Run only when user is logged on для запланированной задачи.

Если другого сеанса входа для учетной записи become нет, для создания нового сеанса входа используется S4U, через который запускается модуль. Это аналогично Run whether user is logged on or not с параметром Do not store password для запланированной задачи. В этом случае процесс become не сможет обращаться к сетевым ресурсам, как и обычный процесс WinRM.

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

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

Ansible можно использовать для перехода к учетной записи Windows без пароля (например, к учетной записи Guest). Чтобы перейти к учетной записи без пароля, настройте переменные обычным образом, но задайте ansible_become_password: ''.

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

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

Флаги Become для Windows

В Ansible 2.5 параметр become_flags был добавлен для метода повышения привилегий runas. Этот параметр можно задать с помощью директивы задачи 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
  ansible.windows.win_copy:
    src: \\server\share\data\file.txt
    dest: C:\temp\file.txt
    remote_src: true
  vars:
    ansible_become: true
    ansible_become_method: runas
    ansible_become_user: DOMAIN\user
    ansible_become_password: Password01
    ansible_become_flags: logon_type=new_credentials logon_flags=netcredentials_only

- name: run a command under a batch logon
  ansible.windows.win_whoami:
  become: true
  become_flags: logon_type=batch

- name: run a command and do not load the user profile
  ansible.windows.win_whomai:
  become: true
  become_flags: logon_flags=

Ограничения Become в Windows

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