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

Директивы become

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

become

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

become_user

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

become_method

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

become_flags

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

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

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

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

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

Чтобы выполнить действие как пользователь nobody при установленной оболочке nologin:

- 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 для краткости). Если вы выполняете playbook, использующий become, и playbook зависает, скорее всего, он застрял на запросе повышения привилегий. Остановите его CTRL-c, затем выполните playbook с -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 (пароль не подразумевается)

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

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

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

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

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

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

• Не удалось установить права доступа на временные файлы, которые 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 для устаревших сетевых playbooks. Для входа в режим 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 }}"

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

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

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

Пользователь должен иметь SeDebugPrivilege для запуска процесса become с повышенными привилегиями. Эта привилегия назначается администраторам по умолчанию. Если привилегия отладки недоступна, процесс 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, которое имеет полный контроль над операционной системой.

• Предоставьте 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 не требуется и игнорируется, если указан.

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

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

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

Использование become без пароля достигается одним из двух методов:

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

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

В случае, если другой вход учетной записи 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 сможет работать с такой учетной записью, необходимо отключить локальную политику Accounts: Limit local account use of blank passwords to console logon only. Это можно сделать либо через объект групповой политики (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. Этот параметр можно задать с помощью директивы задачи 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 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).
• Сервис вторичного входа seclogon должен быть запущен для использования ansible_become_method: runas.
• Пользователь подключения должен быть администратором на хосте Windows для использования runas. Целевой пользователь become не должен быть администратором.