Comments 11
Всё так, только потом apt-get clean не забываем делать
Так зачем? Ну если я свой образ использую для своего проекта, все крутится внутри и не торчит наружу, зачем мне самому себе вставлять палки в колеса в виде нерелевантного кода (обновление не относится к прямым зависимостям моего приложения), невоспроизводимых билдов (ну если версии в apt-get install ещё можно запинить, то системные то не особо), увеличения размера образа? А все ради какой-то сомнительной "безопасности"
многие «особые» пакеты из родительских образов не смогут обновиться внутри непривилегированного контейнера
Здесь имеется ввиду не запуск команд внутри контейнера из под root, а запуск самого контейнера с ключом
--privileged, поэтому ваш советсначала установите обновления безопасности, а затем переключитесь на другого пользователя
не сработает.
К тому же стартовать контейнер и каждый раз стягивать обновления долго. Лучше держите образ с последними обновлениями, а еще лучше держите автоматизированный процесс который будет поддерживать обновления
— Snyk вполне не плохо себя зарекомендовал
— Wazuh монстр для комплексной безопасности
— inspec так же вполне себе не плох
Ну и конечно pre-commit с хуками
Основной аргумент, почему нельзя обновляться через RUN apt-get upgrade и dist-upgrade — это как раз то, что вместе с обновлениями прилетают CVE. Соответственно, сначала нужно проверять пакеты/образы, а только потом их ставить. Далеко не все вендоры выпускают fix в тот же день, когда появляется информация о 0-day, 1-day или уязвимость обретает идентификатор, поэтому с очередным upgrade может запросто прилететь дыра, о которой можно было бы узнать предварительно просканировав.
Автор дает аргументу 3-ий номер и подписывает — «действительно притянуто», «большинству из вас не нужно». Больше реальных фактов против этого нет. Да, это сложно, но это единственный реальный способ получить прозрачную картину о том, что у вас крутится в образе.
Я бы еще добавил один аргумент — " Необходимость прозрачности". Во многих организациях принято вести SBOM (Software Bill of Materials), то есть перечень всех установленных пакетов в xml. Это может понадобится внешнему подрядчику, чтобы передать заказчику, а он в свою очередь проверил, что уязвимостей ни в одном пакете нет. С помощью SBOM можно также быстро выяснить, какие компоненты в системе попали под аффект из-за какой-нибудь новой уязвимости широко распространенной библиотеки, чтобы быстро выпустить компенсирующие меры. Как это делать с upgrade тоже неясно.
согласен ужасные советы в статье, ужасные доводы.
Плохой аргумент №4: обновления не работают
это меня вообще убило... В частности, про Hadolint. Явно статья - неудачный перевод неудачного материала. Из перевода как будто раздел про Linux-хосты с docker, а по изначальному смыслу как будто речь про Linux ВНУТРИ docker... хотя даже там эта мысль очень неудачно сформулирована...
Итоговый результат простой - теперь ко мне будут приходить новички-коллеги и внедрять вот эти вот "вредные" советы, которые статья рекомендует.
Худшие из так называемых «лучших практик» для Docker