Назад | Перейти на главную страницу

Как управлять правами и разрешениями на монтирование привязки для контейнеров, работающих с пользователем без полномочий root?

Мы используем образы контейнеров Red Hat на хостах RHEL, все на основе их образов ubi7 или ubi8, которые по умолчанию запускаются как пользователь по умолчанию (uid 1001).

Это создает проблему, когда контейнеру требуется доступ для записи в каталог хоста (например, для записи журналов или временных файлов), потому что UID и GID хоста сохраняются в контейнере, а файлы, записанные контейнером, будут принадлежать UID. пользователя контейнера.

Это оставляет мне два варианта, насколько я могу судить:

  1. Создайте пользователя на моем хосте с UID 1001 и установите этого пользователя как владельца смонтированного тома. Это может вызвать проблемы, потому что UID 1001 - это первый UID, который будет использоваться при добавлении нового пользователя на хост, где UID не привязан к чему-то конкретному. Следовательно, может быть трудно управлять, если контейнер необходимо развернуть на нескольких серверах, которые могут иметь или не иметь одинаковые согласованные сопоставления UID. Однако это был бы единственный способ, насколько я могу сказать, что владелец файлов, записанных контейнером (с UID 1001), соответствует желаемому пользователю на хосте, и что владелец файлов, записанных на хосте, соответствует существующему UID в контейнер.
  2. Сделайте смонтированный каталог хоста доступным для записи всем, что имеет множество последствий для безопасности, одним из которых является то, что любой пользователь хоста будет иметь доступ для удаления файлов, записанных контейнером. Файлы также могут отображаться как принадлежащие другому пользователю, если UID 1001 уже назначен другому пользователю на хосте.

Обычно я просто создаю соответствующую комбинацию user: group внутри образа контейнера, сбрасываю права собственности и разрешения там, где это необходимо, и перестраиваю его, но для образов, которые создает Red Hat, это подразумевает много работы, так как все сделано для того, чтобы запускается с UID 1001, и существует множество сценариев (разрешения на исправление точки входа в контейнер, создание-пользователя-контейнера), которые заставляют это делать.

Я все правильно понимаю или есть другой (лучший) способ сделать это?

есть ли другой способ сделать это?

Другой вариант - использовать ACL. ACL могут быть гораздо более гибкими, чем просто права пользователя / группы / других стандартных * nix.

Конечно, гибкость списков управления доступом также значительно усложняет их. Вы можете использовать что-то вроде приведенного ниже примера для установки ваших ACL.

Потратьте некоторое время на чтение страниц руководства для acl, setfacl, getfacl и проведите небольшое тестирование, чтобы убедиться, что вы правильно получили свои разрешения. ACL сложны, и ниже приведен только пример.

пример

set_acl скрипт

TMP_DIR_ACL=path/acl_directories
FILE_ACL=path/acl_files
ITEMPATH=/srv/data
OWNER=root
GROUP=root

# set user/group owner on any existing files/dirs
find $ITEMPATH ! -user $OWNER -exec chown --no-dereference $OWNER {} +
find $ITEMPATH ! -group $GROUP -exec chgrp --no-dereference $GROUP {} +
# set acls for all existing direcoties
find $ITEMPATH -type d -exec setfacl --modify-file $DIR_ACL $ITEMPATH {} +
# set acls for all existing files
find $ITEMPATH -type f -exec setfacl --modify-file $FILE_ACL $ITEMPATH {} +
# makes any files created in a directory be owned by the directories group
find $ITEMPATH -type d -exec chmod g+s {} +

acl_directories

group::r-x
mask::rwx
other::r-x
user::rwx
user:1001:rwx
default:group::rwx
default:mask::rwx
default:other::r-x
default:user::rwx
default:user:1001:rwx

acl_files

user::rwX
user:1001:rwX
group::r-X
other::r-X

Я только что понял это ... Образы Red Hat автоматически меняют uid пользователя по умолчанию на то, что вы запускаете контейнер, используя скрипт generate-container-user, поэтому мне просто нужно закончить свой Dockerfile с помощью USER или запустить это с --user, и это работает.