Создание контейнера podman от имени непривилегированного пользователя в Ansible плейбуке, выполняемом от имени root

Вопрос или проблема

Можно ли создать контейнер Podman под другим пользователем, чем тот, который запускает Ansible playbook, используя пространства имен?

Я пишу Ansible playbook для своего виртуального частного сервера. Playbook создает пользователя с правами sudo, выполняет некоторую конфигурацию, а затем устанавливает Podman. Я запускаю этот playbook с помощью ansible-playbook playbook.yaml --ask-vault-pass --user=root --ask-pass, так что он выполняется от имени root (после свежей установки ОС другого пользователя нет).

Затем наступает очередь установки контейнеров. Я использую следующий пример базовой задачи:

- name: Установить Sheetable
  containers.podman.podman_container:
    name: Sheetable
    image: docker.io/vallezw/sheetable
    state: started
    restart_policy: always
    ports:
      - "3333:8080"
    volumes:
      - /home/user/sheetable:/app/config
      - /etc/localtime:/etc/localtime:ro
    env:
      ADMIN_EMAIL="{{ sheetable_admin }}"
      ADMIN_PASSWORD="{{ sheetable_password }}"

Поскольку это устанавливается от имени root, но я хочу установить от имени user, согласно официальной документации, я провел следующие тесты. Для тестов ниже uid=1000 и gid=1000, также <user>:100000:65536 существует в обоих файлах /etc/subuid и /etc/subgid.

  • userns: "keep-id":
    Нет ошибки, контейнер вообще не создается (ни от имени user, ни от root)
  • userns: "keep-id:uid=1000,gid=1000":
    Нет ошибки, контейнер вообще не создается (ни от имени user, ни от root)
  • userns: "keep-id:uid=100000,gid=100000"
    Нет ошибки, контейнер вообще не создается (ни от имени user, ни от root)
  • userns: "auto" + добавление containers:2147483647:2147483648 в файл /etc/subuid и /etc/subgid:
    Нет ошибки, контейнер вообще не создается (ни от имени user, ни от root)
  • user: 1000:1000 + userns: "keep-id:uid=1000,gid=1000":
    Ошибка: keep-id поддерживается только в безрченом режиме
  • user: "user:user" + userns: "keep-id:uid=1000,gid=1000":
    Ошибка: keep-id поддерживается только в безрченом режиме
  • userns: "auto:uidmapping=0:1000:65536":
    Нет ошибки, контейнер создается под root.
  • userns: "auto:uidmapping=1000:0:65536":
    Ошибки: отказ в разрешении на подключение хранилища для контейнера и создание наложенного монтирования, Отмонтирование /var/lib/containers…/merged: недопустимый аргумент
  • userns: "auto:uidmapping=1000:1000:65536":
    Ошибки: отказ в разрешении на подключение хранилища для контейнера и создание наложенного монтирования, Отмонтирование /var/lib/containers…/merged: недопустимый аргумент
  • userns: "ns:<user>":
    Ошибки: отказ в разрешении на подключение хранилища для контейнера и создание наложенного монтирования, Отмонтирование /var/lib/containers…/merged: недопустимый аргумент

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

- name: Установить Sheetable
  become: true
  become_user: "{{ user_name }}"
  containers.podman.podman_container:
    name: Sheetable
    image: docker.io/vallezw/sheetable
    state: started
    restart_policy: always
    ports:
      - "3333:8080"
    volumes:
      - /home/"{{ user_name }}"/sheetable:/app/config
      - /etc/localtime:/etc/localtime:ro
    env:
      ADMIN_EMAIL="{{ sheetable_admin }}"
      ADMIN_PASSWORD="{{ sheetable_password }}"

Но во-первых, я не уверен, что это правильный подход, а во-вторых, я получаю предупреждение

Модуль remote_tmp /home/user/.ansible/tmp не существовал и был создан с режимом 0700, это может вызвать проблемы при выполнении от имени другого пользователя. Чтобы избежать этого, создайте директорию remote_tmp с правильными правами вручную

Возможно ли создать контейнер Podman под другим пользователем, чем тот, который запускает Ansible playbook?

Ваш ответ лежит здесь –> https://www.redhat.com/sysadmin/sudo-rootless-podman

В общем, вы использовали

  become: true
  become_user: "{{ user_name }}"

что не создает сеанс входа для этого пользователя, поэтому возникают проблемы с запуском безречного podman. Если вы хотите запустить этот play, убедитесь, что вы не используете вышеприведенное, а вместо этого ssh на машину, используя этого пользователя (т.е. используйте переменную ansible_ssh_user, сопоставленную с пользователем, который запускает контейнер podman)

Метод по умолчанию become_method для Ansible не устанавливает сеанс входа для пользователя. Один из способов сделать это – создать SSH-сеанс непосредственно для пользователя podman без root, но это, конечно, очень глупо. Альтернативой является использование, например, become_method: machinectl.

Вот что я бы использовал:

- name: Установить Sheetable
  become: true
  become_user: "{{ user_name }}"
  become_method: machinectl
  become_exe: 'sudo machinectl'
  containers.podman.podman_container:

Ответ или решение

Создание контейнера Podman под другим пользователем в Ansible Playbook, работающем от имени root, представляет собой интересную задачу, особенно в контексте работы с rootless Podman. В этом ответе мы подробно рассмотрим возможности и ограничения таких действий.

Проблема

Ваша задача заключается в создании контейнера Podman в Ansible playbook, который запускается от имени root, но вы хотите, чтобы контейнер создавался от имени другого пользователя (например, user). Это необходимо для выполнения безопасных операций, а также для управления правами доступа к ресурсам системы и изоляции контейнеров.

Контекст использования Podman

Podman предоставляет механизмы управления контейнерами без необходимости использования демона и с поддержкой режима "без прав суперпользователя" (rootless). Однако, для успешного создания и управления контейнерами от имени другого пользователя, необходимо учитывать следующее:

  1. Пользовательские пространства имен (user namespaces): Они позволяют контейнерам запускаться с идентификаторами пользователя, отличными от идентификаторов хоста. Это требует, чтобы у пользователя были установлены соответствующие строки в файлах /etc/subuid и /etc/subgid.

  2. Проблемы с привилегиями: Когда playbook запускается от имени root, Ansible не устанавливает сессию для пользователя, что может мешать корректной работе rootless Podman.

Решение через Ansible Playbook

С точки зрения реализации в Ansible, рекомендуем использовать поведение become с подходящими параметрами для установления нужной сессии. Это можно сделать следующим образом:

- name: Установить Sheetable
  become: true
  become_user: "{{ user_name }}"
  become_method: machinectl
  become_exe: 'sudo machinectl'
  containers.podman.podman_container:
    name: Sheetable
    image: docker.io/vallezw/sheetable
    state: started
    restart_policy: always
    ports:
      - "3333:8080"
    volumes:
      - /home/"{{ user_name }}"/sheetable:/app/config
      - /etc/localtime:/etc/localtime:ro
    env:
      ADMIN_EMAIL="{{ sheetable_admin }}"
      ADMIN_PASSWORD="{{ sheetable_password }}"

Объяснение параметров

  1. become: Указывает, что необходимы повышенные привилегии при выполнении задачи.
  2. become_user: Имя пользователя, от имени которого необходимо выполнять команду (в данном случае — это пользователь user).
  3. become_method: В данном примере используется machinectl, что позволяет создать сессию для этого пользователя и обеспечить корректное выполнение rootless Podman.
  4. become_exe: Команда, которая будет использоваться для повышения привилегий, здесь с использованием sudo machinectl.

Предупреждение по созданию временных директорий

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

Заключение

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

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

Оцените материал
Добавить комментарий

Капча загружается...