Comments 20
Все очень правильно написано. Но меня каждый раз передергивает от необходимости фиксировать все версии зависимостей.
RUN apt-get install cowsay=3.03+dfsg1-6
А если пакетов 10, 20, 100? Выглядит так, что на самом деле нужна некая обвязка, которая по условному докерфайлу, который идет с незафиксированными зависимостями и мы его принимаем как "есть", будет генерировать уже полноценный Dockerfile со всеми прописанными зависимостями. Но ни коммерческих решений, ни опенсурсных для этого я не видел. А разработчик… а разработчик чокнется прописывать эти 10, 20, 100 зависимостей на каждый чих… Это, на мой взгляд, вполне автоматизируется и должно быть автоматизировано.
А с node хоть сколько в apt версии пакетов указывай, при yarn install приедет два чемодана node_modules и что там в них никто не знает
Попытки зафиксировать версии пакетов в дистрибутиве приводят лишь на нарастанию устаревших версий в репозитории, не обновляемых годами. Прекращение сопровождения пакета негативно отражается на множестве других пакетов и приводит к ещё большим проблемам. Кроме того, перекрёстные зависимости приводят к тому, что многие библиотеки Node.js становится невозможно деинсталлировать из системы, что, в свою очередь, не позволяет деинсталлировать и другие программы на Node.j
scratch запускает процессы под root'ом, нужно об этом понить
Использование apt-get upgrade, yum update может привести к тому, что внутри вашего контейнера будет произведена установка неизвестного вам ранее ПО, либо ПО уязвимой версии.Обычно это рекомендуется делать, чтобы обновить «системные компоненты» Docker образа: kernel, glibc (если он есть) etc. Потому что со времени выпуска образа контейнера могут выйти обновления фиксирующие баги или улучшающие функционал. С другой стороны: установка неизвестного вам ранее ПО — это вообще из ряда вон выходящее. Откуда оно у вас там взялось? Вот пример Dockerfile:
RUN dnf update -y; \
dnf install -y \
wget \
yarn \
unzip; \
dnf clean all;
Как сюда может затесаться неизвестное вам ранее ПО и тем более не безопасное? Обновление выполняется с официального репозитория.
Использование curl и wget без мер предосторожности позволяет злоумышленнику выполнять скачивание нежелательных компонентов с неизвестных ресурсов (атака «человек-посередине», при которой злоумышленник может перехватить незащищенный трафик и подменить скачиваемый нами пакет на зловредный).Тут что-то всего до кучи: MITM и скачивание нежелательных компонентов с неизвестных ресурсов. Чтобы выполнить атаку «Человек посередине» надо хорошо постараться. Как-то оказаться посередине, произвести подмену во время скачивания. Хлопотно это. Куда чаще мелькают новости, что в известных репозиториях обнаруживается подмена оригинальных пакетов на сторонние, либо у известных пакетов обнаруживается странные незаявленные возможности. Это всё куда клоню? Доверяй, но проверяй. И тестируй собранные образы.
Теперь немного не по теме.
Секреты могут по ошибке помещаться в качестве параметра инструкции ENV или передаваться внутрь образа как текстовый файл.С этим уже надо постараться, чтобы оно оказалось по ошибке в Dockerfile.
В случае, если злоумышленнику удастся заполучить shell внутри вашего контейнера, он может оказаться root'ом, что сильно упростит дальнейшую атаку с выходом за пределы контейнера.В большинстве случаев не требуется выход за пределы окружения контейнера (чтобы не светиться) и повышение привилегий тоже. Если основное приложение работает от непривилегированного пользователя, то и неосновное тоже будет работать.
RUN dnf update -y; \
dnf install -y \
wget \
yarn \
unzip; \
dnf clean all;
легко. Вы не контролируете, что там в манифесте НОВОЙ ВЕРСИИ пакета, который придет. Там запросто может быть новая зависимость (новый пакет). И я уже писал, что новая версия пакетов wget/yarn/unzip в общем случае может притянуть что-то еще.
Обычно это рекомендуется делать, чтобы обновить «системные компоненты» Docker образа: kernel, glibc (если он есть) etc
лучшая рекомендация — собрать новый базовый образ с новыми запаренными "системными компонентами". И уже из него собирать новый прикладной образ.
Чтобы выполнить атаку «Человек посередине» надо хорошо постараться
не нужно стараться. Любой мобильный провайдер делает перехват HTTP. Я был очень удивлен, когда на Мегафоне вместо скачивания пакета с дебиан оф репо подсовывается что угодно, кроме исходного файла.
Доверяй, но проверяй. И тестируй собранные образы.
это никуда не девается )
В большинстве случаев не требуется выход за пределы окружения контейнера (чтобы не светиться) и повышение привилегий тоже. Если основное приложение работает от непривилегированного пользователя, то и неосновное тоже будет работать.
Злоумышленнику же хочется запустить там Майнер. Или в соседние поды (если речь про кубер) сходить. Все равно будет щупать на предмет «сходить и повысить себе привилегии», а не тихонько сидеть у себя в уголке )
легко. Вы не контролируете, что там в манифесте НОВОЙ ВЕРСИИ пакета, который придет. Там запросто может быть новая зависимость (новый пакет). И я уже писал, что новая версия пакетов wget/yarn/unzip в общем случае может притянуть что-то еще.точно так же как и не контролируете что в самом wget. С таким подходом можно дойти до абсурда. Или вы серьезно считаете, что ментейнеры дистрибутива (Debian/Ubuntu/RHEL) не заметят какой то левой зависимости?
не нужно стараться. Любой мобильный провайдер делает перехват HTTP.что мешает использовать https?
что мешает использовать https?
никто не мешает ) пользуйтесь — я разрешаю. А вообще смысла особо для репозиториев RPM/DEB в https нет — там все подписано ключами GPG. Проблема в первую очередь с curl | sh, ну, и потенциальной доступностью репы в целом.
точно так же как и не контролируете что в самом wget. С таким подходом можно дойти до абсурда.
нет, но мне это и не нужно. Мне нужна конкретная версия wget.
Или вы серьезно считаете, что ментейнеры дистрибутива (Debian/Ubuntu/RHEL) не заметят какой то левой зависимости?
не "левой", а нежелательной для меня.
Проблема в первую очередь с curl | sh, ну, и потенциальной доступностью репы в целом.ну если вы запускаете curl | sh, то ССЗБ. О какой безопасности мы тогда вообще говорим ))
не «левой», а нежелательной для меня.есть конкретные примеры? Когда при обновлении прилетали «нежелательные» зависимости и именно из-за них возникали уязвимости/риски?
ну если вы запускаете curl | sh, то ССЗБ. О какой безопасности мы тогда вообще говорим ))
По первому в статье есть солюшен, как можно сделать, без организации своего «доверенного» репо:
RUN curl -sSL -o redis.tar.gz \
http://download.redis.io/releases/redis-3.0.1.tar.gz \
&& echo "0e21be5d7c5e6ab6adcbed257619897db59be9e1ded7ef6fd1582d0cdb5e5bb7 \
*redis.tar.gz" | sha256sum -c -```
Любой мобильный провайдер делает перехват HTTP. Я был очень удивлен, когда на Мегафоне вместо скачивания пакета с дебиан оф репо подсовывается что угодно, кроме исходного файла.
Чтоа? А вы не разбирались с Мегафоном почему оно так?
Спасибо огромное за статью. Было очень интересно!
yum update может привести к тому, что внутри вашего контейнера будет произведена установка неизвестного вам ранее ПОможно примеры в студию в контексте RHEL? У меня за 15 лет использования, что то ничего неизвестного не устанавливалось при yum update
либо ПО уязвимой версии.как раз отсутствие yum update скорее приведет к ситуации с дырявым ПО. Или вы предлагаете смотреть changelog на все установленные пакеты?
$ docker run -it --rm centos:7 rpm -qa | wc -l
147
Или вы предлагаете смотреть changelog на все установленные пакеты?
честно — да, это трудоемко. Но оголтелый update (смотрим в общем, не только на RHEL, а вообще) может сделать по очевидным соображениям хуже, чем есть сейчас.
Я уж не говорю о том, что RHEL (именно RHEL) внутри контейнеров очень редко используют — все больше alpine/ubuntu/centos...
Лучшие практики при написании безопасного Dockerfile