Понимание повышения привилегий: 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.

become_flags

(на уровне play или task) разрешает использование определённых флагов для задач или ролей. Одно из распространённых применений — изменение пользователя на nobody, когда оболочка установлена на no login. Добавлено в 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, когда оболочка — nologin:

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

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

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

ansible_become

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

ansible_become_method

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

ansible_become_user

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

ansible_become_password

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

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

webserver ansible_user=manager ansible_become=yes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нельзя ограничивать права повышения привилегий определенными командами. Ansible не всегда использует конкретную команду для выполнения действия, но выполняет модули (код) из временного файла с именем, которое изменяется каждый раз. Если вы разрешили команды `/sbin/service` или `/bin/chmod`, это приведет к сбою Ansible, поскольку эти пути не будут соответствовать временному файлу, который 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 режим или режим привилегированного EXEC) на всех поддерживаемых Ansible платформах, которые поддерживают режим enable. Использование become заменяет опции authorize и auth_pass в словаре provider.

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

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

Включение режима для всех задач

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

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

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

- 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 — это привилегия высокого уровня, предоставляющая полный контроль над операционной системой. По умолчанию ни одному пользователю не назначается эта привилегия, и следует проявлять осторожность при её предоставлении пользователю или группе. Подробнее об этой привилегии см. в Act as part of the operating system. Для настройки этой привилегии на хосте 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 работало только в Windows с локальным или доменным учетной записью пользователя. Локальные учетные записи службы, такие как System или NetworkService, не могли быть использованы как become_user в этих более ранних версиях. Это ограничение было снято с момента выпуска Ansible 2.5. Три учетные записи служб, которые можно задать в become_user, следующие:

• Система
• 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
  win_regedit:
    path: HKLM:\SYSTEM\CurrentControlSet\Control\Lsa
    name: LimitBlankPasswordUse
    data: 0
    type: dword
    state: present

Флаги become для Windows

Ansible 2.5 добавил параметр become_flags к методу become 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
  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
  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 работает только при использовании 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