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

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

• Использование become

  • Директивы become
  • Переменные подключения become
  • Командные параметры become

• Риски и ограничения become

  • Риски повышения привилегий до непривилегированного пользователя
  • Не поддерживается всеми плагинами подключения
  • Только один метод может быть включён на хост
  • Повышение привилегий должно быть общим
  • Невозможно получить доступ к переменным среды, заполненным pamd_systemd

• Become и автоматизация сетей

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

    • Пароли для режима включения
  • authorize и auth_pass

• Become и Windows

  • Права администратора
  • Локальные учётные записи службы
  • Become без установки пароля
  • Учётные записи без пароля
  • Флаги become для Windows
  • Ограничения become в Windows

Использование become

Вы можете управлять использованием become с директивами play или task, переменными подключения или в командной строке. Если вы задаёте свойства повышения привилегий несколькими способами, ознакомьтесь с общими правилами приоритета, чтобы понять, какие настройки будут использованы.

Полный список всех плагинов become, включённых в Ansible, можно найти в списке плагинов.

Директивы become

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

become

устанавливается в yes для активации повышения привилегий.

become_user

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

become_method

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

become_flags

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

Например, чтобы управлять системной службой (требующей 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 при shell nologin:

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

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

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

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

ansible_become

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

ansible_become_method

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

ansible_become_user

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

ansible_become_password

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

ansible_common_remote_group

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

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

webserver ansible_user=manager ansible_become=yes

Командные параметры become

--ask-become-pass, -K

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

--become, -b

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

--become-method=BECOME_METHOD

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

--become-user=BECOME_USER

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

Риски и ограничения become

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

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

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

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

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

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

Далее, если POSIX ACL недоступны или 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 считает результат успешным и не продолжает проверку allow_world_readable_tmpfiles как указано ниже.

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

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

Существует несколько способов полностью избежать указанного выше логического потока:

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

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

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

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

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

Можно активировать только один метод на хост

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

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

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

Нельзя получить доступ к переменным среды, заполненным pamd_systemd

Для большинства дистрибутивов Linux, использующих systemd в качестве init, используемые по умолчанию методы 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.

Become и сетевая автоматизация

С версии 2.6 Ansible поддерживает become для повышения привилегий (переход в режим enable или режим привилегированного выполнения) на всех поддерживаемых Ansible сетевых платформах, поддерживающих режим enable . Использование become заменяет параметры authorize и auth_pass в словаре provider.

Для использования become для повышения привилегий на сетевых устройствах тип подключения должен быть установлен на connection: ansible.netcommon.network_cli или connection: ansible.netcommon.httpapi. Подробности см. в документации к Параметрам платформ.

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

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

Invalid input (privileged mode required)

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

- name: Gather facts (eos)
  arista.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)
      arista.eos.eos_facts:
        gather_subset:
          - "!hardware"

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

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

group_vars/eos.yml

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

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

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

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

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: yes
        auth_pass: " {{ secret_auth_pass }}"

Рекомендуется обновить ваши книги задач, чтобы использовать become для сетевых устройств enable режима последовательно. В будущем использование словарей 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 попытается выполнить модуль с полными правами, доступными удалённому пользователю. Если повышение прав пользователя не удастся, оно продолжит использование ограниченного токена во время выполнения.

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

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

- Check my user name
  ansible.windows.win_whoami:
  become: yes

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

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, которое имеет полный контроль над операционной системой.

• Предоставьте SeTcbPrivilege пользователю, с которым Ansible подключается через WinRM. 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 не требуется и игнорируется, если указан.

Повышение прав без указания пароля

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

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

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

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

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

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

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

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

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

Прежде чем повышение прав сможет работать для такой учётной записи, необходимо отключить локальную политику Учётные записи: Ограничить локальное использование пустых паролей только для консольного входа. Это можно сделать через объект групповой политики (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

Флаги повышения прав для 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 войти в систему пользователя при создании нового процесса. Значение может быть установлено в «ничего» или в комбинации следующих:

• 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: yes
  vars:
    ansible_become: yes
    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: yes
  become_flags: logon_type=batch

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

Ограничения повышения прав в 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).
• Сервис вторичного входа seclogon должен быть запущен для использования ansible_become_method: runas