🐳 Почему процессы в контейнерах Docker не должны запускаться от имени Root

Процессы в контейнере Docker не должны запускаться от имени root.

Безопаснее запускать приложения от имени пользователя, не являющегося root, которое вы указываете в Dockerfile или при использовании docker run.

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

В этой статье вы узнаете об опасностях, связанных с запуском контейнерных приложений от имени root.

Вы также увидите, как создать пользователя, не являющегося root, и настроить namespacing в ситуациях, когда это невозможно.

Почему запуск от имени Root опасен?

По умолчанию контейнеры запускаются от имени root.

Демон Docker запускается от имени root на вашем хосте, и запущенные контейнеры также будут запускаться от имени root.

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

Разделение обеспечивается только механизмами изоляции контейнеров Docker.

Нет прочной физической границы; ваш контейнер – это еще один процесс, запущенный пользователем root на ядре вашего хоста.

Это означает, что уязвимость в вашем приложении, среде выполнения Docker или ядре Linux может позволить злоумышленникам выйти из контейнера и выполнить операции с правами root на вашей машине.

Существуют некоторые встроенные средства защиты, которые снижают риск возникновения такой ситуации.

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

Несмотря на эти меры, разрешение запуска приложений от имени root остается опасным.

Так же, как вы ограничиваете использование root в традиционной среде, неразумно без необходимости использовать его в контейнерах.

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

Запуск контейнеризированных приложений от имени пользователя, не являющегося привилегированным пользователем

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

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

Вы должны создать новую учетную запись пользователя как один из последних этапов в вашем Dockerfile.

Этого можно добиться с помощью инструкции USER:

FROM base-image:latest
RUN apt install demo-package
USER demo-user:demo-group
ENTRYPOINT ["demo-binary"]

Контейнеры, запущенные с этого образа, будут работать под именем demo-user.

Пользователь будет членом группы demo-group.

Вы можете опустить имя группы, если вам не нужно, чтобы пользователь состоял в группе:

USER demo-user

Вместо имен можно указать идентификатор пользователя (UID) и идентификатор группы (GID):

USER 950:950

Выделение известных UID и GID обычно является самым безопасным способом.

Это предотвращает сопоставление пользователя в контейнере с чрезмерно привилегированной учетной записью хоста.

USER часто указывается как предпоследняя ступень в Dockerfile.

Это означает, что вы все еще можете выполнять операции, требующие root, на более ранних этапах сборки образа.

Инструкция apt install в приведенном выше примере имеет законную потребность в root.

Если бы инструкция USER была размещена выше, apt был бы запущен от имени demo-user, который не имел бы необходимых прав.

Поскольку инструкции Dockerfile относятся только к сборкам образов, а не к запущенным контейнерам, безопасно оставить изменение пользователя на более поздний период в Dockerfile.

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

Установите права на все пути, которые будут использоваться вашим приложением:

COPY initial-config.yaml /data/config.yaml

USER demo-user:demo-group
RUN chown demo-user:demo-group /data

В этом примере каталог /data должен принадлежать demo-user, чтобы приложение могло вносить изменения в свой конфигурационный файл.

Предыдущий оператор COPY скопирует файл от имени root.

Можно воспользоваться сокращенным вариантом, используя флаг –chown вместе с copy:

COPY --chown=demo-user:demo-group initial-config.yaml /data/config.yaml

Предыдущий оператор COPY скопирует файл от имени root.

Можно воспользоваться сокращенным вариантом, используя флаг –chown вместе с copy:

$ docker run -d --user demo-user:demo-group demo-image:latest
$ docker run -d --user demo-user demo-image:latest
$ docker run -d --user 950:950 demo-image:latest

Флаг –user запускает процесс контейнера от имени указанного пользователя.

Он менее безопасен, чем инструкция Dockerfile USER, поскольку вам придется применять его отдельно к каждой команде docker run.

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

FROM image-that-runs-as-root:latest
USER demo-user

$ docker build . -t image-that-now-runs-as-non-root:latest

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

Вы можете попробовать вручную изменить права на пути, вызывающие проблемы.

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

Работа с приложениями, которые должны запускаться от имени root

Разделение имен пользователей – это техника работы с приложениями, которым нужны некоторые привилегии root.

Она позволяет сопоставить root внутри контейнера с пользователем, не являющимся root, на вашем хосте.

Имитированный root в контейнере имеет необходимые привилегии, но вынос не даст root-доступа на хост.

Ремаппинг пространства имен активируется путем добавления поля userns-remap в файл /etc/docker/daemon.json:

{
    "userns-remap": "default"
}

Использование default в качестве значения для userns-remap инструктирует Docker автоматически создать нового пользователя на вашем хосте под именем dockremap.

Root в контейнерах будет отображаться на dockremap на вашем хосте.

При желании можно указать существующего пользователя и группу, используя комбинацию UID/GID или имя пользователя/имя группы:

{
    "userns-remap": "demo-user"
}

Перезапустите демон Docker после применения изменений:


sudo service docker restart

Если вы используете nsuser-remap: default, пользователь dockremap теперь должен существовать на вашем хосте:


id dockremap
uid=140(dockremap) gid=119(dockremap) groups=119(dockremap)

Пользователь также должен появиться в файлах идентификаторов /etc/subuid и /etc/subgid:

$ dockremap:231500:65535

Пользователю выделен диапазон из 65 535 подчиненных идентификаторов, начиная с 231500.

В пространстве имен пользователей идентификатор 231500 сопоставлен с 0, что делает его корневым пользователем в ваших контейнерах.

Будучи UID с высоким номером, 231500 не имеет привилегий на хосте, поэтому атаки на взлом контейнеров не смогут нанести такой большой ущерб.

Все запущенные вами контейнеры будут работать с измененным пространством имен пользователей, если вы не откажетесь от этого с помощью docker run –userns=host.

Механизм работает путем создания каталогов с разнесенными именами внутри /var/lib/docker, которые принадлежат подчиненным UID и GID пользователя с разнесенными именами:

$ sudo ls -l /var/lib/docker/231500.231500

total 14
drwx------ 5 231500 231500 13 Jul 22 19:00 aufs
drwx------ 3 231500 231500 13 Jul 22 19:00 containers
...

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

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

Перед использованием этой опции следует изучить документацию.

Заключение

Запуск контейнерных приложений от имени root представляет собой риск для безопасности.

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

Root в контейнере – это тот же root, что и root на вашем хосте, поэтому успешная компрометация может обеспечить контроль над вашей машиной.

Как автор образа, вы должны включить инструкцию USER в свой Dockerfile, чтобы ваше приложение запускалось без root.

Пользователи образа могут отменить эту инструкцию с помощью docker run –user, чтобы назначить определенные UID и GID. Это поможет смягчить ситуацию, когда образ обычно использует root.

Вы можете еще больше усилить безопасность, удалив все возможности из контейнера с помощью –cap-drop=ALL, а затем включив в белый список те, которые необходимы, с помощью флагов –cap-add.

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

см. также: