Проанализировав состав свежих образов, представленных в официальных репозиториях Docker, исследователи обнаружили (https://www.federacy.com/docker_image_vulnerabilities), что в 11% из них присутствуют неисправленные опасные уязвимости, а в 13% уязвимости средней степени опасности. Для проверки использовалась утилита vuls (https://github.com/future-architect/vuls), оценивающая версии установленных пакетов на наличие известных уязвимостей. Для сравнения, похожее исследование, проведённое два года назад среди официальных образов, помеченных как самые свежие (выставлен тег "latest"), показало (https://www.opennet.me/opennews/art.shtml?num=42322) наличие наличие опасных уязвимостей в 23% образов и уязвимослей средней опасности в 24%.Меньше всего уязвимостей было выявлено в образах, построенных на пакетной базе Debian (8.33%), а больше всего опасных уязвимостей было найдено в образах на базе Ubuntu (26.67%), при том, что на базе Ubuntu построено 16% из рассмотренных образов Docker, а на базе Debian - 79%. Наиболее часто встречающейся проблемой названа уязвимость CVE-2016-8610 (https://www.opennet.me/opennews/art.shtml?num=45442), которую можно использовать для инициирования отказа в обслуживании сервера через наводнение специально оформленными пакетами. Из опасных уязвиомостей лидером стали проблемы CVE-2016-4658 (https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2...) и CVE-2016-1252 (https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2...) в libxml2 и apt, которые встречаются в 5% рассмотренных образов.
URL: https://www.federacy.com/docker_image_vulnerabilities
Новость: http://www.opennet.me/opennews/art.shtml?num=46192
Вот тут бы всяким поклонникам snap-ов и им подобных решений задуматься, но...
Не задумаются, ибо есть +100500 более серьёзных проблем, которые доскер/аппимаге/снап - как-то решили.
Например: Никто не променяет возможность переползания сервера БД с одной машины на более быструю на отсутствие дубликаций библиотек.
Ещё, такие универсальные средства распространения приложений действительно решают проблему распространения приложений. Собирать 100500 пакетов только для линукса - это не очень удобно, кстати, наш Дженкинс делает это в доскере. Угадайте почему....
потому что вы поклонники Hype Drive Development
https://blog.daftcode.pl/hype-driven-development-3469fc2e9b2...
Эти умные слова не к месту немного. Особенно в моём случае. Несколько лет назад, когда не было докеров/аппимагов/снапов, в них была такая же необходимость, как и сегодня. И тогда я делал чруты с софтом, паковал их в squashfs, короче, неделя уходила на то, чтобы сделать программу переносимой. И да, тащить openvz и lxc за собой она не должна.
С появлением доскера я вздохнул с облегчением.
> … тащить openvz и lxc за собой она не должна. С появлением доскера я вздохнул с облегчением.Странная логика. Т.е. openvz или lxc — это оверхед, а докер - нормалёк?...
там и докера не было. В те времена.
Прямо таки целая неделя? И на каждый деплой? Или все таки один раз сделал и работает?
один раз написал скрипт для сборки. Типа сегодняшнего Dockerfile, но без докера.
> И тогда я делал чруты с софтом, паковал их в squashfs, короче, неделя уходила на то, чтобы сделать программу переносимой.А пакетные менеджеры тогда ещё не изобрели?
>> И тогда я делал чруты с софтом, паковал их в squashfs, короче, неделя уходила на то, чтобы сделать программу переносимой.
> А пакетные менеджеры тогда ещё не изобрели?Как бы, разные вещи, пакетник суть просто распаковщик.
>> переносимой.Именно переносимой!
Счас тебе скажут что собрать десяток пакетов под все сборки линукса не проблема, и ты просто не осилил. Как не осилил и сопровождение по зависимостям и прочим изменениям по типу моча вголову дистроклепателям.
Точно! :)
просто кто-то не осилил OBS
Плюсую, делал тоже самое, писал самопальные обвязки(что суть была, докер) над lxc и сквашем.
Собственно все разговоры вокруг "о боже не юникс вей зависимости обновление" они как бы лет 5+ как летают вокруг таких тем. Теперь вот и докер под нож попал.
Ребята, вам никто не мешает работать так как вам удобно, не мешайте и нам.По сабжу:
1. Там на докерхабе гребаная свалка. Понимайте это или умрите.
2. Тестировать стоит только звезданутые(официальные) образы, ибо от них только и откалываются при работе нормальные пацаны, остальное содержимое хаба просто помёт нечистоплотных девопсов.
3. Этот кипиш всего лишь результат временного отсутствия автопроверки на уязвимости на хабе, тулзов достаточно, операция рутинная. Пока это все на плечах конечных пользователей.
> 2. Тестировать стоит только звезданутые(официальные) образы, ибо от них только и откалываются
> при работе нормальные пацаны, остальное содержимое хаба просто помёт нечистоплотных девопсов.Разуваем глаза и читаем:
> Проанализировав состав свежих образов, представленных в _официальных_ репозиториях Docker, исследователи обнаружили
Если б тестировали всё подряд, результат был бы порядка 99%. На всякий случай, для тех кто не в курсе: чтобы получить статус официального образа, надо его обновлять не реже раза в неделю. И даже несмотря на это официальщики так обос#ались.
Хз, я откалываюсь от aws docker image и делаю апдейт+установку барахла на каждой мажорной сборке приложения. Тулзы еще ни разу не бибикали в CI процессе на уязвимости.
У них список уязвимых реп есть?
> нечистоплотных девопсов.а бывают другие?
Странно, потому как хоть Docker и смен backend на свой, проблемы связанные с ядром решить нельзя, хотя бывает необходимость в этом и не часто
я вот хз как у вас поворачивается язык называть контейнеры переносимыми. понятно, что несколько лет назад гиперов не было.
>наш Дженкинс делает это в доскере. Угадайте почему....Что то мне страшно, может стоит заменить дженкинс на красивый gitlab-ci-multi-runner
ну или тимсити.
да хоть и на мезос, хоть это и некрасиво. Всё это по сути - таскраннеры.
Кстати, каким молодчиком выглядит rhel: ни одной серьёзной уязвимости не выявлено. Вот только если debian - 79% рассмотренных контейнеров, а ubuntu - 16%, значит на rhel остаётся... 5%? Ясно-понятно. =)
> Кстати, каким молодчиком выглядит rhel: ни одной серьёзной уязвимости не выявлено. Вот
> только если debian - 79% рассмотренных контейнеров, а ubuntu - 16%,
> значит на rhel остаётся... 5%? Ясно-понятно. =)Молодец, возьми с полки пирожок ;)
А на самом деле выглядит это так, что возможно было рассмотрено (а возможно и не рассмотрено, по причине очень сильной "необходимости") до 5% образов обозначенной Вами организации.
Вот, еще в одной помойке нашли кучу дырявого софта, а все потому-что хыпстеры не могут осилить lxc и самостоятельно готовить контейнеры для соих целей
Да тут дело даже не столько в создании контейнеров, сколько в том, что на их сопроводжение естественно кладётся болт.
А чего там сопровождать? Они по определению одноразовые. Те, кто используют один контейнер дольше 10 минут, — ССЗБ.
> А чего там сопровождать? Они по определению одноразовые. Те, кто используют один
> контейнер дольше 10 минут, — ССЗБ.А у меня время жизни контейнера соизмеримо с временем жизни хоста.
Тогда на фига докер? С него весь профит в том, что контейнерами можно жонглировать как хошь. Если это не нужно, LXC будет более адекватным решением.
> докер
> LXCТеорему Эскобара доказываете?
Я один из тех хипсторов, готовивший контейнеры самостоятельно. До появления доскера, разумеется. Потом перестал.
Но ты ведь пцон ровный и правильный, сам пишешь ось, прикладное и даже системное ПО под каждую задачу на каждой ЭВМ. Повторное использование чужого труда - не нужно, так ведь?
Как показало данное исследование, как минимум 11% докеровских контейнеров не повторное использование чужого труда, а повторное использование чужих криворукости, лени и наплевательского отношения к безопасности.
11% - очень даже неплохо, как для начала.
Так это не начало, а продолжение. В начале было 23%. Читайте в новостях не только заголовки.
до появления докера это называлось chroot и почему вы считаете что до докера только вы это готовили не понимаю, на chroot наяривали до прихода во фрю джэйлов и в последствии зон в соялрку.
да, у меня это был чрут, и не полновесный, а сильно усечённый, но с докером сегодня удобнее. Я так и не понял чего вы не поняли.
почему вы себя хипстером называете?
Да плевать, разве не для этого придумали изолированные контейнеры?
Ну то есть то, что твой контейнер потенциально делает из твоей машинки звено ботнета для рассылки спама, ддоса или ещё чего - тебя не волнует, ибо "основная система изолирована"?
Потенциально любой необслуживаемый сервер тоже звено ботнета, давайте все потушим?
> Потенциально любой необслуживаемый сервер тоже звено ботнета, давайте все потушим?Давайте. Если б они были кому-нибудь нужны, их бы обслуживали.
рили? похоже ты не умеешь в реальность.
Нет, это кто-то не умеет в автоматизацию.
>> Ну то есть то, что твой контейнер потенциально делает из твоей машинки звено ботнета для рассылки спамаТо же самое делает не обновленный вовремя пакет, или устаревший пакет из репозитория.
Проблема из сабжа не есть проблема контейнеров, как и устаревшие пакеты в репозитории не проблема пакетного менеджера. Это проблема - майнтенера и политики докерхаба. Естественно в данной ситуации внимательно смотреть что ты качаешь и запускаешь.
Контейнер из доверенного источника может послужить на пользу. Например, в нем можно запустить последний зафикшеный Nginx, обновленная версия которого еще не появилась в оф. репозитории или она вообще не появиться. Так что технология полезная если пользоваться с включенной головой.
Нет. Просто нет. Контейнеры нужны не для деплоя серверов. Это какие-то извращенцы придумали. Они нужны для того, чтобы в изолированном окружении заупстить какую-нибудь проприетарщину, например. Или для быстрого формирования сборочного окружения. Но почему вы серверы деплоите? Идея сродни снапу, не иначе.А пример с nginx любопытен тем, что абсолютно не понятно, на кой чёрт тебе там докер-контейнер. Ну вышел патч, ну собери и установи через checkinstall. Это ведь лучше, чем запустить последний зафикшенный nginx работать с уязвимым окружением в контейнере?
> Нет. Просто нет. Контейнеры нужны не для деплоя серверов. Это какие-то извращенцы
> придумали.увы, девопы это придумали. В смысле докера, для остальных были lxc+openvz. И всякие atomic hosts они же.
идея на бумаге была очень красива - вместо dependency hell внутри системы (три версии пехепе по номерам, две - по версиям одинаковы но в них разные версии шибконужного кривого модуля, и смотри не перепутай, с каким префиксом запускать pecl - кстати, как у тебя с умением собирать pecl'овые автопонатащеные зависимости в пакет, будь он деб или rpm? И то же самое с пихоном (там с модулями попроще, но есть пара своих, где баг исправили, версию не поменяли, не забудь стереть старые .egg везде где их ухитрилось отложить - напоминаю, оно умеет гадить под себя) - ну и там, по мелочи, три boost'а, скажем. Нет, это я не из пальца высосал, это я в старую шпаргалку глянул) получаем законченные черные ящички, из которых можно _автоматически_ (чего у тебя нет с lxc и прочей виртуализацией) собрать правильную этажерочку, а если кто под себя чем нагадил - оно откладывается на промежуточный слой.> А пример с nginx любопытен тем, что абсолютно не понятно, на кой чёрт тебе там докер-
> контейнер.пример дурацкий, да - если тебе нужно и ты успеваешь до майнтейнеров дистрибутива, пора бы и собственным репо озаботиться, с правильно и вовремя собранным.
но вот хатю не просто нгынх, а нхынх собранный с boring ssl "как у больших" (и мне тут модуль по дружбе подогнали от этого большого, который только с ним живет). При этом не сломай мне какой-нибудь curl, который дергает скриптомашина, причем не через бинарник, а через lib, и еще стотыщ запчастей, о которых ты можешь даже и не знать (и нет, вот это все пересобирать вручную из-за ssl не хотю, к тому же оно может собраться, но не работать). И нет, ДВА раздельных /etc/ssl - тоже не годится.
бессмысленное исследование. Во-первых, все эти уязвимости получаются из-за необновленных версий пакетов и лечатся банальным apt update && apt dist-upgrade. Во-вторых, кому какое дело до уязвимости в libxml в каком-нибудь контейнере с монгой, который хорошо если светит наружу одним портом? В-третьих, в любом сколько-нибудь сложном продакшне контейнеры собираются вручную.
> бессмысленное исследование. Во-первых, все эти уязвимости получаются из-за необновленных версий пакетов и лечатся банальным apt update && apt dist-upgrade.Вот только хипстеры выше таких скучных вещей, как обновление ПО.
> Во-вторых, кому какое дело до уязвимости в libxml в каком-нибудь контейнере с монгой, который хорошо если светит наружу одним портом?
Совсем недавно пролетала новость про 100500 вывешенных в мир контейнеров с монгой.
> В-третьих, в любом сколько-нибудь сложном продакшне контейнеры собираются вручную.
Вот только на практике я встречал много больших и крупных компаний, где используют первый попавшийся образ аргументируя "ну оно же работает, и так сойдёт"
1 - сам себе противоречишь
2 - да, это проблема контейнеров... ну-ну...
3 - сиска, нетфликс, эрикссон, властелины епама, властелины сцыклума. Ну, это так, навскидку, что инсайдеры поведали.
> Совсем недавно пролетала новость про 100500 вывешенных в мир контейнеров с монгой.А при чем здесь Docker?
> Вот только хипстеры выше таких скучных вещей, как обновление ПО.Когда насяльника требует, чтоб вчера контейнер был запущен, а сегодня в него только целевое содержимое подогнали, то "обновление ПО" это очень второстепенная задача.
За всех судить не берусь, но в случае умения расставлять правильно приоритеты, на обновление ПО приходится забивать.
Это я проективно, работаю не в ИТ
> и лечатся apt update && apt dist-upgradeт.е. сначала заворачиваем в докер чтоб "поставил и забыл", а потом не забываем и обновляем? решение: в докерах которые обновляем ставим докеры, которые поставил и забыл!
Нет.- apt update && apt upgrade - в докерфайле на сборочнице. Обновление - это сборка нового образа.
- остальное - при перезапуске контейнера/пода.
>> и лечатся apt update && apt dist-upgrade
> т.е. сначала заворачиваем в докер чтоб "поставил и забыл", а потом не
> забываем и обновляем? решение: в докерах которые обновляем ставим докеры, которые
> поставил и забыл!Ты, наверное, не в курсе, но решается это действительно просто. Dockerfile всего лишь начинается со строк:
FROM ubuntu:16.04
RUN set -x \
&& apt-get -y update \
&& apt-get -y upgrade \
&& apt-get install -y --no-install-recommends ...после чего любая пересборка образа решит вопрос с кошмарными уязвимостями, о которых кричат окружающие. Совсем ленивые могут две команды по сборке и заливке образа в крон запихнуть.
> после чего любая пересборка образа решит вопрос с кошмарными уязвимостями, о которых
> кричат окружающие. Совсем ленивые могут две команды по сборке и заливке
> образа в крон запихнуть.проблема не в том, что я знаю или не знаю. проблема в том, что часть раздающих докеры про это не знает, да и часть потребляющих тоже.
Вот и не волнуйся. Тебе это всё равно не грозит.
На него навалятся 100500 ботов с каждого из 100500 докер-контейнеров поднятых школотой. А это уже серьёзно.
а мне, мне тоже не волноваться? а то я волнуюся: вдруг мне нужно волноваться?
> Dockerfile всего
> лишь начинается со строк:
> FROM ubuntu:16.04
> RUN set -x \
> && apt-get -y update \
> && apt-get -y upgrade \
> && apt-get install -y --no-install-recommends ...
> после чего любая пересборка образа решит вопрос с кошмарными уязвимостями, о которых
> кричат окружающие. Совсем ленивые могут две команды по сборке и заливке
> образа в крон запихнуть.Да-да, берём дырявый образ, обновляем его дырявым apt и плодим ноды ботнета.
> Из опасных уязвиомостей лидером стали проблемы <...> CVE-2016-1252 (https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2...) в <...> apt, которые встречаются в 5% рассмотренных образов.
вы докером-то пользовались хоть раз? пересборка такого докерфайла приведет к тому что докер возьмет закешированную версию предыдущей сборки, а значит все дыры будут на месте.
Я в свое время с этим боролся. обновляя таймстамп в комментарии в докерфайле. Докер после этого считает, что это уже новый докерфайл, и не берет ничего из кешей.
а потом не забываем а забиваем.
> бессмысленное исследование. Во-первых, все эти уязвимости получаются из-за необновленных
> версий пакетов и лечатся банальным apt update && apt dist-upgrade.и кто же собирается это делать - в каждом инстансе каждого контейнера, который тебя угораздило запустить?
> Во-вторых, кому какое дело до уязвимости в libxml в каком-нибудь контейнере с монгой,
> который хорошо если светит наружу одним портом?потому что если в этот порт (или в десяток забытых собирателем контейнера соседних) нельзя засунуть ломающий xml - значит, в контейнере просто лишняя библиотека (что возможно, конечно). А если она таки нелишняя - то добро пожаловать в те 11%.
> В-третьих, в любом сколько-нибудь сложном продакшне контейнеры собираются вручную.
а нахрена тогда? В сколько-нибудь сложном продакшне обычно не идет речи о запуске на одном хосте ста контейнеров, в нем идет речь о "как бы нам еще и вот эту хреновину распилить, чтобы можно было запускать ее на стойке серверов, а желательно на двух, на разных континентах".
Контейнер в этом случае удобен только тогда, когда за тебя его уже кто-то собрал.
вобщемта
git pull Dockerfile
docker build
docker run
не особо сложнее
apt-get update
apt-get upgrade
systemctl restartНадо только смотреть что в докерфайле и использовать официальные образы.
Первичная настройка сложнее, зато потом удобно разворачивать.
Желаю видеть такие-же регулярные отчеты об анализе на уязвимости каталога дополнений вротпресс и друпал. Иначе эта вся кампания как-то странно выглядит.
> Желаю видеть такие-же регулярные отчеты об анализе на уязвимости каталога дополнений
> вротпресс и друпал.как ты докера-то обocрал...
> Иначе эта вся кампания как-то странно выглядит.
как бе дополнения к вордпрессу вполне себе компактны и поддаются человеческому анализу (поштучно, конечно, а не когда тебе внезапно достался сайт с неведомым их количеством)
контейнеры - только если вот автоматически чем-то проверять, без гарантий, при этом.
(не говоря уж про сам докер, который тоже в принципе неанализируем)
>> Иначе эта вся кампания как-то странно выглядит.
> как бе дополнения к вордпрессу вполне себе компактны и поддаются человеческому анализу
> (поштучно, конечно, а не когда тебе внезапно достался сайт с неведомым
> их количеством)
> контейнеры - только если вот автоматически чем-то проверять, без гарантий, при этом.
> (не говоря уж про сам докер, который тоже в принципе неанализируем)Вся ручная проверка контейнера укладывается в {yum, apt} upgrade. Просто кто-то предпочитает доверять поставщику реп, а кто-то после этого этапа еще запускает тулзы для доп проверок.
Тред пестрит страхами тех кто ничего не понимать в том что такое контейнер но точно быть уверенным что это зло и дыра.
Необновленный контейнер сейчас такая-же популярная штука как и необновленный сервер, решаеют эту проблему одинаковыми методами, с безопасностью - аналогично. Здесь и обсуждать нечего.
> Вся ручная проверка контейнера укладывается в {yum, apt} upgrade.и так со всеми стапятьюдесятью контейнерами, которые понадобились именно на этой вот системе (из них 100 в силу dependency hell ;-) Не забыть 140 из них разрешить внешние сетевые подключения, ибо они тому, что работает внутри контейнера, вообще-то нахрен не нужны.
Нет ,ты правда собираешься это делать - вручную аттачиться к каждому, выяснять - yum тут или apt или вообще zypper, запускать, обломиться о давно отключенный репозиторий, все это вручную устранять - с немалой вероятностью что завтра приедет новая версия (ночью, автоматически - разрабу было в это время работать приятнее, а походу он поправил зависимость на одну цифирку вверх - и да, у него-то "все тесты прошли, раскатываем на прод") и тебе все надо делать заново?> Необновленный контейнер сейчас такая-же популярная штука как и необновленный сервер
число серверов конечно, внутри серверов стоит софт, отдельный от узкоспециализированной задачи, решаемой сервером, который и апдейтит их, и следит за тем чтобы апдейты не обломились об unresolvable/нет сети/недоступен repo, все это мониторится, и никакой разработчик не притащит за собой на веревочке свой, ни с чем несовместимый, с экзотическим дистрибутивом внутри.
Контейнер собран за тебя кем-то, кто об этом думал в последнюю очередь, если было чем.
Число контейнеров потребных для работы чего-то нетривиального - ограничено только фантазией разработчиков.То есть я с удовольствием послушаю истории успеха как лично тебе удалось поставить это под контроль, но пока - увы и ах, обычный FUD.
> Необновленный контейнер сейчас такая-же популярная штука как и необновленный сервер, решаеют
> эту проблему одинаковыми методами, с безопасностью - аналогично. Здесь и обсуждать
> нечего.Это справедливо для традиционных контейнеров, где крутится полноценная система (в том числе cron или другой демон, ставящий обновления безопасности автоматом), но не для докер-контейнеров, в которых традиционно запускается единственное приложение, и которые обновляются путём разворачивания свежего образа.
> Это справедливо для традиционных контейнеров, где крутится полноценная системау полноценной системы как раз есть полноценный автообновлятор, если его специально не сломать.
А у докер-контейнера ничего нет, и доступа в сеть нормального тоже - кроме упомянутого выше "единственного порта, на котором слушает [дырявая] монга".Ну и у полноценной системы - полноценные админы, с полноценной ответственностью. А не девелоперы, которым срочно нужно почесать зависимость от очередного неведомого нагромождения хлама, а если что - "мы не виноватые, оно шамо приполжло".
Короче, всё как всегда: хочешь хорошо - сделай сам.
> Короче, всё как всегда: хочешь хорошо - сделай сам.самому на порядок проще воспользоваться полноценным отдельным сервером/виртуальным/lxc/ovz/банальным сhroot в зависимости от необходимой степени изоляции (и уровень этой необходимости оценить самому, под конкретную задачу).
докер и паблик репо становятся нужны, когда сделайсам не прокатывает по причине ограниченности ресурса самоделкина, а система сложная и "должна работать".
Ну классика жDocker - это отличная возможность переложить проблемы поддержания актуальных версий системных библиотек (того же самого openssl) с поставщиков ОС и системных администраторов на никого. После того, как проблемы безопасности окружения переложены на никого, скорость внедрения и эксплуатации заметно возрастает, ведь производительность никого ограничена только супремумом пофигизма, а он, в свою очередь, верхней границы не имеет (с)
> Ну классика жamarao неточен. Надо было поставить точку после "возрастает".
> производительность
> никого ограничена только супремумом пофигизма, а он, в свою очередь,пофигизм тут не причем.
Даже если тебе НЕ пофиг, как только ты начал таскать контейнеры из репо (неважно, общедоступного или корпоративного), а не собирать их сам (что в случае докера, мягко говоря, странная идея) - у тебя уже нет никакой физической возможности уследить за их содержимым. Справиться бы хотя бы с тем, чтобы вовремя сами контейнеры обновлялись, и ничего при этом в системе не порушить...
Вообще частично проблему решает интеграция в CI сканеров, например - https://github.com/coreos/clair
По-хорошему нужно использовать образы наследованные от Alpine Linux, там будет меньше дырявого хлама
> у тебя уже нет никакой физической возможности уследить за их содержимым.а кто мешает после сборки образа запустить тот же ansible playbook и убедиться, что у вас нет уязвимых версий пакетов?
> По-хорошему нужно использовать образы наследованные от Alpine Linux, там будет меньше дырявого хлама
а там что, какие то другие версии apache/php/java? Они не подвержены уязвимостям?
> а кто мешает после сборки образа запустить тот же ansible playbook и убедиться,
> что у вас нет уязвимых версий пакетов?отсутствие внутри скачанного из репо-помойки образа ansible, плейбука к оному с учетом особенностей всех неведомых дистрибутивов, на основе любого из которых може быть собран контейнер, достаточных прав в конфиге.
итого на каждый, приехавший по зависимостям образ, тебе надо - добавить ненужные в продакшн пермишны, добавить свои скрипты проверки, запустить, проконтролировать что они именно сработали, а не обломались о неверный угадав местного пакетного менеджера или еще какую специфичную проблему, если нашлась уязвимость - добавить _еще_ пермишнов чтобы таки суметь втащить апдейты (если они вообще есть, а не образ собран на базе давно неподдерживаемой ветки), убрать все пермишны, кроме дефолтных, и можно вздохнуть спокойно, пока не приедет следующий.
Я даже верю, что это, в принципе, можно процентов на 90 автоматизировать, блокируя раскатывание на прод оставшихся 10 до ручного вмешательства. Правда, понадобится _очень_ изрядный запас процессорной и дисковой мощности, очень немалое время квалифицированного э...назовем это девопом, и понимание руководства, чем это ты тут занимаешься третий месяц, когда поставлена задача "перейти на использование docker вместо этих ваших костылей и подпорок".
Но не верю, что где-то это сделано.Истории успеха, по прежнему, хотелось бы услышать.
у нас в проде используется два дистра ubuntu 14.04/16.04. Так что никаких проблем нет. Если у вас зоопарк, то кто вам виноват