Комментарии 13
До адептов Docker никак не может дойти, что Docker не повышает безопасность, а снижает ее.
Контейнеры Docker как минимум плохо поддаются аудиту, а как максимум способствуют тому, чтобы разработчики лепили корявый и непереносимый софт.
Контейнеры Docker как минимум плохо поддаются аудиту, а как максимум способствуют тому, чтобы разработчики лепили корявый и непереносимый софт.
НЛО прилетело и опубликовало эту надпись здесь
>в котором абсолютно четко расписано как создается контейнер
В котором чётко прописано, что следует использовать внешнюю библиотеку такую-то версии от 2013-го года при том, что на официальном сайте давно лежит от 02.2019-го сборка и между той, что была в 2013 и той, что есть в 2019-м — десяток багфиксов, и среди них N-е количество security fix'ов.
Конечно, и security bug'ов добавилось с тех пор (как, возможно, и производительности насыпали, и каких-нибудь кривых зависимостей убрали), но атакующий-то о невыявленных пока ещё багах вряд ли что-то знает, поэтому будет рад софту, в котором куча дыр, описанных в security-бюллетенях за прошедшие 5 с лишним лет.
А почему такую замшелую библиотеку разработчики пихают в докер-контейнер? А потому что с ней — всё работает! Вот работало оно в 2013-м году, и в 2019-м работает. И, собственно, я не ошибусь, если скажу, что именно ради подобного (описание можете сами подставить по смыслу фразы) разработчики используют docker-контейнеры чаще всего. Они им нужны для того, чтобы с одной стороны таскать с собой целый ворох чужих библиотек, а с другой стороны — не дай Бог не подстраиваться к целевой системе. А то вдруг там библиотека не 2013-го года и скомпилированная, например, не со столь заботливо подобранными флагами, сакральные знания о которых передаются из поколение в поколение?
Безусловно, докер-контейнеры — это не про безопасность, и даже не про упаковку зависимостей, покрывающихся мхом и плесенью. Но большинство разработчиков используют докер не по назначению, а именно в качестве этакого грязного дырявого мешка, в который плотно набиваются все нужные костыли, чтобы при переносе на другую систему чудесное приложение не рассыпалось от ужасного столкновения с объективной реальностью, существующей где-то за рамками тестовых сред и разработческих макбуков.
В котором чётко прописано, что следует использовать внешнюю библиотеку такую-то версии от 2013-го года при том, что на официальном сайте давно лежит от 02.2019-го сборка и между той, что была в 2013 и той, что есть в 2019-м — десяток багфиксов, и среди них N-е количество security fix'ов.
Конечно, и security bug'ов добавилось с тех пор (как, возможно, и производительности насыпали, и каких-нибудь кривых зависимостей убрали), но атакующий-то о невыявленных пока ещё багах вряд ли что-то знает, поэтому будет рад софту, в котором куча дыр, описанных в security-бюллетенях за прошедшие 5 с лишним лет.
А почему такую замшелую библиотеку разработчики пихают в докер-контейнер? А потому что с ней — всё работает! Вот работало оно в 2013-м году, и в 2019-м работает. И, собственно, я не ошибусь, если скажу, что именно ради подобного (описание можете сами подставить по смыслу фразы) разработчики используют docker-контейнеры чаще всего. Они им нужны для того, чтобы с одной стороны таскать с собой целый ворох чужих библиотек, а с другой стороны — не дай Бог не подстраиваться к целевой системе. А то вдруг там библиотека не 2013-го года и скомпилированная, например, не со столь заботливо подобранными флагами, сакральные знания о которых передаются из поколение в поколение?
Безусловно, докер-контейнеры — это не про безопасность, и даже не про упаковку зависимостей, покрывающихся мхом и плесенью. Но большинство разработчиков используют докер не по назначению, а именно в качестве этакого грязного дырявого мешка, в который плотно набиваются все нужные костыли, чтобы при переносе на другую систему чудесное приложение не рассыпалось от ужасного столкновения с объективной реальностью, существующей где-то за рамками тестовых сред и разработческих макбуков.
Какие-то страшилки для детей рассказываете. Вот, к примеру, репка с кучей докерфайлов.
github.com/vimagick/dockerfiles. Хоть один там найдете такой, как вы описали? Нет, не найдете. Все из пакетов, все с апстрима.
Прибивают еще иногда питон, ноду, акей, но у них специфика такая. Их запакетировать полностью просто невозможно. Так это не проблема докера, разработчики это делают абсолютно на всех системах одинаково.
Из сорцов еще иногда ставят, но там тоже все понятно с флагами и ключами. В докерфайле никакой магии нет, будет сделано все, как написано. Хорошо написано — хорошо будет сделано. Если написано плохо, результат будет, ожидаемо, соответствующий.
Также в нормальных registry уже давно все имаджи сканируются Clair, например, ну и подписываются до кучи.
Ну и разве разработчики «замшелые библиотеки» только в докер пихают? Вам пора менять взгляды, докер и подобные сервисы в тренде, миллионы людей это используют. Проблемы есть, но плюсов ощутимо больше.
Объективности ради. В объективной реальности существуют огромные кучи отвратного софта, которые даже в докер никак не поместить, не залезет. Их даже большие компании пишут. И за килобаксы умудряются продавать. Там не то что на другую систему перенести, даже обновить без курса психотерапии не выйдет. Так и крутится, пованивая из-под капота чудесным. Без всякого докера.
github.com/vimagick/dockerfiles. Хоть один там найдете такой, как вы описали? Нет, не найдете. Все из пакетов, все с апстрима.
Прибивают еще иногда питон, ноду, акей, но у них специфика такая. Их запакетировать полностью просто невозможно. Так это не проблема докера, разработчики это делают абсолютно на всех системах одинаково.
Из сорцов еще иногда ставят, но там тоже все понятно с флагами и ключами. В докерфайле никакой магии нет, будет сделано все, как написано. Хорошо написано — хорошо будет сделано. Если написано плохо, результат будет, ожидаемо, соответствующий.
Также в нормальных registry уже давно все имаджи сканируются Clair, например, ну и подписываются до кучи.
Ну и разве разработчики «замшелые библиотеки» только в докер пихают? Вам пора менять взгляды, докер и подобные сервисы в тренде, миллионы людей это используют. Проблемы есть, но плюсов ощутимо больше.
Объективности ради. В объективной реальности существуют огромные кучи отвратного софта, которые даже в докер никак не поместить, не залезет. Их даже большие компании пишут. И за килобаксы умудряются продавать. Там не то что на другую систему перенести, даже обновить без курса психотерапии не выйдет. Так и крутится, пованивая из-под капота чудесным. Без всякого докера.
У docker-а скорее другая проблема: он не подходит для низкоуровневых highload приложений, вроде сетевого ввода/вывода на основе poll mode-драйвера IGB UIO на сервере с несколькими 40-гигабитными карточками. По очевидным причинам IGB UIO или KNI на docker-ах не запустить, а иначе сложно выжать соответствующую производительность
А не-highload приложения, не столь критичные к ресурсам, можно запускать и на виртуалках, или что еще лучше — в serverless-облаке.
А highload, но не низкоуровневые?
Я думаю тут подменено понятие HPC. Highload это одно и может иметь отношение к огромной системе которая обслуживает сотни миллионов запросов в секунду, будучи слегка нагруженной в расчёте на один хост. HPC подразумевает обработку максимально возможного количества данных нагружая все доступные вычислительные ресурсы в пределах одной ноды и это определённо не highload в терминах распределённых сервисов.
Уважаемые читатели! А вы уже защитили свои системы от уязвимости runC?
Нам пофигу, у нас немодный LXC.
Уже было: habr.com/ru/company/flant/blog/439964
Да, неужели ru_vds сложно вбить «runc» в поиске хабры перед тем, как публиковать дубль?
Работает только с предварительно криво слепленным специальным контейнером. Как и большинство уязвимостей в Linux, сводится к тому, что
«SSHD remote root exploit found. A Remote attacker who knows root password can gain root access unless it's explicitly disabled in SSHD configuration.»
«SSHD remote root exploit found. A Remote attacker who knows root password can gain root access unless it's explicitly disabled in SSHD configuration.»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Уязвимость runC, затрагивающая Kubernetes, Docker и containerd