Зачем запускать сервисы в контейнере от имени непривилегированного пользователя?

Помимо различных статей, это советуется и в официальной документации:

If a service can run without privileges, use USER to change to a non-root user


Но ведь речь идет не про хост, и сервис уже изолирован от окружающей системы, зачем дополнительно понижать пользователю привилегии? Допустим, злоумышленник нашел способ провести RCE через сервис в контейнере, что конкретно он сможет сделать плохого от рута, чего не смог бы, если бы сервис был запущен, как советуется?

Я честно искал в интернете, но единственный хоть какой-то конкретный сценарий эксплуатации рутовой учетки начинался со слов "А сейчас мы примонтируем корневой раздел хоста внутрь контейнера", что само по себе малость неадекватно.

К сожалению, я пока не смог проникнуться доводами вроде "так безопаснее, потому что так безопаснее". Я вижу только ненужное усложение в конфигурации контейнера - помимо прочего, теперь нужно еще не забыть создать группу\пользователя и проследить, чтобы сервис имел доступ к нужным файлам\директориям\портам\etc.

В чем же разница?
  • Вопрос задан
  • 950 просмотров
Пригласить эксперта
Ответы на вопрос 2
vasilevkirill
@vasilevkirill
Сертифицированный тренер MikroTik TR0417
рассказать вам что может сделать пользователь root с mysql?
Или может сертификаты nginx/apache вместе с закрытыми ключами тоже всем пользователям отдать напрямую?

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

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

у меня сложилось впечатление, что контейнеризация сервисов для Вас является серебряной пулей безопасности. к примеру, есть хостинг и на нем есть дырявые сайты, которые чуть ли не каждый день хакают и через них сливают данные с других сайтов т.к. не проставлен open_basedir и все работает под апачем без разделения через SuID или без mpm-itk. и тут Вы познакомились з контейнеризацией и теперь запустили каждый сайт в своем личном окружении и все чики-пики с безопасностью. пример надуманый мною и не факт, что оно так у Вас на самом деле, но суть не в том

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

вот с чем я сталкивался лично и что мне просто не давало жить. представим, что Вы создали сервис, который дополнительно еще генерирует какие-то файлы. файлы хранится в некоторой папочке в `/foo/bar/beez_service`, но Вы в эту папку монтируете другую папку хост-машины. Ваш сервис запущен от рута. Ваш сервис пишет лог и все эти файлы генерируются с правами рута и с неким chmod-ом, который был указана через umask или еще как-то. обычно над этим не заморачиваются и файлы имеют chmod 0664 - обычным пользователем удалить его невозможно. это как минимум неудобно. я понимаю, Вы можете ответить, что монтировать папки не всегда нужно, что можно использовать `sudo` на хост-машине, что не особо нужно удалять файлы через хост-машину и так далее
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы