Почему бы не использовать пользователя root по умолчанию - PullRequest
1 голос
/ 26 июня 2019

Я читал две темы о безопасности Docker:

https://docs.docker.com/engine/security/security/

https://medium.com/@mccode/processes-in-containers-should-not-run-as-root-2feae3f0df3b

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

Но как насчет образов разработки?Образы Docker, которые используются, когда мне нужно создавать приложения, а не запускать службы?

В настоящее время я использую не-root пользователя для образов образов, но я вижу некоторые преимущества при его использовании.Например, когда я хочу использовать свой образ Docker в MS Azure, работающем как задание контейнера, для него требуется пользователь root.Кроме того, когда мне нужно обновить свой образ, например, установить новый пакет, мне нужно повысить права этого пользователя, у которого есть разрешение sudo.

Наконец, есть реальная рекомендация для пользователя без полномочий root в образах Docker,когда изображение только для разработки и строительства?

С уважением!

Ответы [ 2 ]

1 голос
/ 27 июня 2019

Вот замечательное введение в то, чем на самом деле является контейнер: https://www.slideshare.net/jpetazzo/anatomy-of-a-container-namespaces-cgroups-some-filesystem-magic-linuxcon

Контейнеры - это процессы linux, работающие в одном и том же ядре, разделенные пространствами имен и ограниченные cgroups.

Процесс внутри контейнера имеет идентификатор пользователя (UID) и идентификатор группы (GID), связанный с ним: по умолчанию UID равен 0 (что соответствует корню).

ЕслиПроцесс внутри контейнера может взаимодействовать с ресурсами вне контейнера (такими как файловая система базового хоста), тогда он будет делать это с правами доступа, связанными с UID / GID этого процесса.Таким образом, в примере, где он работает с UID 0 (root), этот процесс может получить доступ и изменить все файлы на базовом хосте, что, как правило, плохо.(Если вы используете SELinux, тогда это не так просто, но давайте не будем усложнять ситуацию).

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

Кроме того, вы единственный, кто создает эти образы контейнеров?Очевидно, вы доверяете себе, но если другим разрешено создавать подобные контейнеры, доверяете ли вы им?Как, на самом деле, действительно им доверять?Ваши контейнеры могут быть в порядке, но как насчет их?Можете ли вы гарантировать, что они (злонамеренно или по ошибке) не позволят своим контейнерам получать доступ к файловой системе или ресурсам основного хоста?

Рекомендуется, чтобы ваш контейнер никогда не работал с UID 0. Естьв некоторых случаях, когда это абсолютно необходимо, а в корпоративных средах это огромный красный флаг для контейнера, который будет настроен таким образом, и очень часто ваш контейнер не будет запускаться системами безопасности компании.Если вы должны запустить контейнерный процесс с UID 0, то рассмотрите возможность использования переназначения пространства имен пользователя (описано здесь и здесь и в других местах), что является способом, которым контейнер выполняет процесс с UID0 внутри контейнера (так что процесс контейнера считает его корневым), вне контейнера процессу присваивается совершенно другой (непривилегированный) UID.

0 голосов
/ 26 июня 2019

Одной из сильных сторон докеров является то, что ваша среда разработки точно имитирует то, что произойдет в prod

Позвольте мне дать вам случай / ошибку, которая у меня была

Мы используем nginx в качестве нашего веб-сервера, я ограничил prod только изображениями для корневого доступа, и при разработке все выглядело нормально. После выпуска я понял, что nginx имеет буфер запроса 16 КБ, когда он превышает его, он записывает его на диск (у пользователя без полномочий root не было разрешений на это), и он возвращает клиенту ошибку 500.

На dev все выглядело нормально, до тех пор, пока я не получил запросы на prod больше порога 16K.

...