Пользователь
0,0
рейтинг
25 мая 2015 в 00:42

Разработка → Печальное состояние сисадмина в эпоху контейнеров перевод

Системное администрирование сейчас в печальном состоянии. Оно в хаосе.

Я не говорю про олдскульных админов, они знают как управлять системами и контролировать обновления.

Проблема в контейнерах, готовых виртуальных машинах (prebuilt VMs), а также в невероятном хаосе, который они создают, потому что в их концепции не хватает «доверия» и «обновлений».

Давайте взглянем на Hadoop. Судя по всему, никто не знает как собирать Hadoop с нуля; это просто огромная куча из зависимостей, необходимых версий и утилит сборки.

Ни одна из «замечательных» утилит не собирается традиционной командой make. Каждая утилита поставляется со своим собственным не переносимым и не совместимым c чем-либо «методом дня» для сборки.

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

Рай для вирусов и АНБ. Больше не нужно эксплуатировать уязвимости в безопасности; достаточно просто сделать «приложение», «виртуальную машину» или «образ для Docker» и позволить людям скачать этот инфицированный код к себе в сеть.

Типичным примером будет викистраница в дебиане, посвящённая Hadoop. По существу, люди отказались от своих попыток собирать Hadoop с нуля для дебиана и предлагать качественные пакеты ещё в 2010 году.

Чтобы собрать Apache Bigtop, по-видимому, требуется сначала установить puppet3. Позвольте ему выкачать магические данные из интернета и попытаться запустить sudo puppet, чтобы включить бакдоры от АНБ (например, он скачает и установит устаревший JDK, потому что он считает вас слишком тупым, чтобы установить джаву). Ну а потом надейтесь, что gradle не выплюнет 200 строчек бесполезных ошибок.

Я не шучу, он попытается запустить такие команды как:

/bin/bash -c "wget http://www.scala-lang.org/files/archive/scala-2.10.3.deb ; dpkg -x ./scala-2.10.3.deb /" 

Заметьте, он даже не устанавливает пакет правильным образом, а лишь распаковывает его в ваш корневой каталог. Во время загрузки не проверяется никаких подписей и даже SSL-сертификатов (источник: Bigtop puppet manifests)

Даже если сборка пройдёт нормально, то всё равно она будет использовать неподписанные бинарники, скаченные из Maven'а.

Сегодня, вместо чистой модульной архитектуры везде огромная куча заблокированных зависимостей (interlocked dependencies). В последний раз, когда я видел classpath Hadoop'а, он уже состоял из более 100 jar-файлов. Готов поспорить, что сейчас там их 150, даже без использования HBaseGiraphFlumeCrunchPigHiveMahoutSolrSparkElasticsearch или ему подобных из Apache.

Stack — это новый термин, означающий «я понятия не имею, что я на самом деле использую».

Maven, ivy и sbt — это утилиты для скачивания неподписанного кода и запуска его на вашем компьютере.

С контейнерами этот хаос ещё хуже.

Когда-нибудь пробовали сделать обновление безопасности для контейнера?

По существу, подход Docker'а состоит в скачивании неподписанных бинарников, запуске их, и надежды, что они не содержат бакдоров для сети вашей компании.

Мне это напоминает shareware для винды из девяностых.

Когда появится первый Docker-образ, содержащий тулбар от Ask? Первый интернет-червь, распространяющийся через Docker?

Все эти годы дистрибутивы Linux пытались предоставлять вам надёжные операционные системы, с подписанными пакетами, собранными из сети доверия (web of trust). Некоторые даже работают над воспроизводимыми сборками.

А потом, всё стало виндофициривано. «Приложения» стали безумием, которое вы скачиваете и запускаете даже не задумываясь о безопасности или способах обновления. Потому что «мы живём лишь один раз».

Update: меня поправили, что это началось ещё до Docker'а: «Docker — это новый 'curl | sudo bash'». Это так, но сейчас стало особенно популярно скачивать и запускать недоверенное ПО в своём «датацентре». И это очень плохо.

Раньше админы прилагали все усилия, чтобы предотвратить уязвимости в безопасности; а теперь они называют себя «devops» и вводят эти дыры в свою сеть самостоятельно!
Перевод: Erich Shubert
Дмитрий @cdkrot
карма
16,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (99)

  • +5
    >Давайте взглянем на Hadoop. Судя по всему, никто не знает как собирать Hadoop с нуля; это просто огромная куча из зависимостей, необходимых версий и утилит сборки.

    Я вас скажу так, его собрать с 0 не знали как и 5 лет назад. Лично мне пришлось перечитать кучу документации и написать скрипты.
    Обновлять его, это был еще более крутой квест — особенно в продакшене.

    С другой стороны, опытные админы становится все меньше нужны. Всем начинай подавай devops.
    Знай и bash и python,go, mysql, mongo,puppet,salt итд итп. В итоге ты знаешь это все, но не глубоко.

    Беда эта и у программистов, пока выучишь один фреймворк, появится другой, третий сотня их.

    Сейчас я на распутье куда идти дальше работать, админы не нужны, начинать программировать как то не хватает сил.
    • +2
      В DevOps идти, пока не поздно еще. На самом деле, выбора не будет просто, так что можно не торопиться с решениями: все там будут.
      • +2
        Я хотел с начало года с головой погрузится в python, да же получил 100% сертификат на stepic но!
        Решил самостоятельно изучит разговорный английский, профита будет больше :)
        • +3
          Может Вам и русский еще пригодится, что ж вы его так…
          • 0
            >Может Вам и русский еще пригодится, что ж вы его так…

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

            (тут очень печальный котик)

            Если есть мысли, как мне помочь — я только за.
  • +5
    Ох, как вы (т.е. автор оригинала) правы… Современное IT — это мастодонты. Столько слоев абстракции, что уже давн нет одного человека или хотя бы группы, разбирающейся в них всех. Интересно, что с этим всем произойдет в итоге — ИМХО оно просто не может не обрушиться под своим весом в один прекрасный момент.

    Что касаетс docker, контейнеров и безопасности, то, я думаю, ситуация с бинарниками и ненадежным кодом не улучшится. Однако все более будет улучшаться ситуация с «песочницами»: песочница внутри песочницы внутри песочницы и т.д. Т.е. ну и пусть там внутри одной из песочниц что-то происходит небезопасное — оно все равно наружу не вылезет. Возьмем для примера Amazon EC2: они ведь разрешают по определению запускать *любой* код, но это не ставит под угрозу безопасность инфраструктуры Амазона. Это только аналогия, а не прямое сравнение: не надо его на docker-контейнеры распространять. Суть в том, что надежность и безопасность системы все более определяется не надежностью кода, а надежностью различных внешних ограничителей (типа песочниц, но не совсем и не обязательно).
    • +1
      не вижу проблем в количество слоёв абстракций, если каждый их них кристально прозрачен.

      Проблема именно в том, что в какой-то момент «люди отказались». Но опять-же, не вижу принципиальных проблем добавить слой подписей в maven (ivi, sbt). Как только в jar'никах поймают закладки — сделают это очень быстро.
      • +2
        Ну в Maven Central без подписи загрузить библиотеку невозможно. Да, сами сборочные инструменты подписей не проверяют, но я более чем уверен что в Gradle или SBT использовать соответствующий плагин возможно (или написать самостоятельно, если его ещё нет). Вот, например.
        • +1
          о! значит для jvm-мира, основа уже есть, и то, что этим не пользуются — суть лень, неорганизованность, и отсутствие паранойи.

          Но вон, в соседних комментариях затронули мир JS, там видимо всё не так радужно
          • +1
            лень, неорганизованность, и отсутствие паранойи.

            Да, по-видимому, всё именно так :)
            • 0
              Ну это постепенно улучшается, вон central стал по https отдавать, а не по http, как раньше
              • 0
                Не, я конечно понимаю, что в 21 веке https — вершина прогресса, но всё же пакеты нужно именно подписывать.
                Почему?
                А вы уверены, что репозиторий отдаёт тот же файл, что в него загрузили? А вы уверены, что получаете такой же файл, как и весь остальной мир? Вполне можно взломать сервер и пропатчить его так, чтобы пара подсетей получала другой архив, отличающийся от версии для остальных.
                • 0
                  Это вопрос доверия. Вы доверяете лично всем мейтейнерам debian/fedora/whatever, ключи которых используются для подписи пакетов? Вы проверили, что вы зашли на настоящий debian.org/fedoraproject.org/whatever или вы доверяете 200+ root ca?
                  • +1
                    Ну это не только вопрос доверия, речь именно о том, что в такой архитектуре взломанный сервер может отдавать что-то не то, и этого даже никто не заметит.
                    В том, что я зашёл на настоящий debian.org я уверен из-за https. В том, что я получаю обновления от комманды дебиана я тоже уверен, потому что всё подписано gpg. Доверяю ли я маинтейнерам? Ну вообще протащить что-то левое в исходники человеку со стороны очень сложно — всё проверяется, работа должна быть «спонсированой» существующим разработчиком дебиана, который естественно просмотрит весь код.

                    Не надо делать вид, будто ситуация симметричная: можно доверять или не доверять дебиану, можно доверять или не доверять hadoop/maven/…
                    Дебиану доверяют именно из-за его процесса разработки, который приводит к высокому качеству и надёжности. И у него нет проблем с исходниками. Если я захочу почитать исходники пакета, то я могу их загрузить за пару минут (apt-get source).
                    • +1
                      Ситуация несимметричная, это очевидно: в случае debian есть два звена (https и gpg), keychain получается пользователем редко; в случае maven по-умолчанию используется только https (но можно включить проверку подписи всех артефактов с помощью стороннего плагина). Сервера debian, конечно, можно тоже поломать и положить левый keychain в дистрибутивы, а потом подписывать левым gpg-ключом. Но вероятность того, что это быстро заметят существенно выше. И большая часть пользователей не пострадает, т. к. keychain у них уже есть.

                      Подход с доверенным keychain'ом и gpg мне нравится, т. к. позволяет без проблем создавать зеркала. Но с уязвимыми точками в нём всё не так гладко: если у кого-то из большого количества мейнтейнеров сперли ключ, то зарелизить на своё зеркало левак не составляет труда. Насколько это сложно в плане релиза в основной репозиторий — не знаю; оно зависит от принятого процесса релиза.
                      • +1
                        Нельзя так просто подменить gpg-ключи (это называется keyring, а не keychain), потому что keyring лежит в соответсвующем debian-пакете debian-keyring. Ну и так просто подменить его нельзя: во-первых если вы тихо выкладываете обновление пакета с keyring, а в новостях на сайте тишина, то это уже большие подозрения; а во вторых debian-keyring — это тоже пакет, и он тоже подписан этими ключами, поэтому до того момента, как вы его обновите валидация будет идти по старым ключам, и все сразу увидят, что «что-то тут не так».

                        Не знаю как именно производится отзыв ключа (о таком слышать не приходилось, всё-таки люди следят за своими ключами), но я думаю, что одного ключа мало будет: наверняка нужен ещё пароль на загрузку; более того к замороженному stable вообще невозможно получить доступ без позволения release-team и ftp-masters.
                        • 0
                          это называется keyring, а не keychain
                          Оговорился. Для gpg называется keyring. В других реализациях pki называется по разному: keychain, keystore/truststore и т. п. Сути не меняет.

                          Я имел ввиду следующий вектор атаки: подменяется дистрибутив (iso), в который включён пакет debian-keyring. Также можно отдавать свой список зеркал в том же дистрибутиве, чтобы не затёрли скомпрометированный keyring.

                          Не знаю как именно производится отзыв ключа (о таком слышать не приходилось, всё-таки люди следят за своими ключами)
                          Обычно создаётся revocation certificate для мастер-ключа и мастер-ключ не хранится на машинах, которые имеют доступ к сети. А subkeys отзываются мастер-ключом и публикуются на keyserver. Вопрос в том, как скоро другие люди из WoT получат обновление с keyserver'а. В случае наличия пакета *-keyring — как обновят систему.

                          одного ключа мало будет: наверняка нужен ещё пароль на загрузку; более того к замороженному stable вообще невозможно получить доступ без позволения release-team и ftp-masters.
                          Это уже административные меры, но при компрометации сервера они ни о чём. Скорее заметят неожиданное обновление пакета.

                          И, кроме того, я рассматривал вариант подмены на зеркале, а не в основном репозитории (в том числе, с помощью прозрачной прокси). Этот вектор устраняется, если подписи отдаются с доверенного сервера по https.
                          • 0
                            Про подмену начиная с iso:
                            Можно так конечно сделать, только вам тогда придётся поддерживать собственное зеркало и просто так вас всё равно в официальный список зеркал не включат. А если кто-нибудь решит сменить зеркало, то подстава обнаружится.

                            про ключи:
                            Ну да, просто обновят. Если речь о больших дыренях подобного уровня, то шумиха поднимается быстро и сильная.

                            Про неожиданное обновление пакета:
                            Ну, как я уже сказал, доступ на загрузку есть далеко не у всех (и только в unstable, дальше полуавтоматические миграции), остальные проходят проверку на качество у спонсора. Ещё есть отдельные тимы, которые занимаются независимой проверкой пакетов QA (quality assurance), Security team.
  • +12
    Не докером единым, всякие npm, bundle и иже с ними вместо нормальных системных зависимостей качают черт знает что в папку пользователя и это всё культивируется как мейнстрим.
    • –5
      По поводу npm спорить не буду — хуже системы менеджмента зависимостей я еще не видел, но в чем проблема с bundle? Забыли добавить https для «source»? подписаные gem-ы ключем (хоть и не все) не достаточно? папку пользователя лишним он не засоряет, как я замечал.
      • +1
        Тем что каждый пользователь ставит свои пакеты, а сервисы (потенциально выставленные наружу) могут быть уязвимы, например, потому что пользователь забыл их обновить.
        • +1
          Извините, не понял. Какие сервисы и почему они уязвимы?
          • +1
            Ну вот кто-то поставил какую-то программу себе в home. Версия библиотеки прописана жестко в bundle, например. Допустим в библиотеке критический баг. Чтобы она пропатчилась, нужно чтобы автор программы исправил версию в bundle, а потом пользователь обновил программу и выкачал новую версию библиотеки.

            И так для каждой программы и каждого пользователя.
            • +1
              Я думаю такая же проблема и для многих утилит. Homebrew тоже обновляет утилиты по запросу. Очень часто нужно делать обновление руками и с apt/yum/ports. Автообновление есть не у многих программ (например в Mac Os это достигнуто с помощью App Store, но разработчику нужно платить $100 ежегодно и проходить ревью приложения каждый раз).
      • +3
        > в чем проблема с bundle?

        В том, что каждое рельсоприложение тащит с собой свой Gemfile.lock с прикрученными гвоздями версиями гемов, а если это дело попытаться обновить — то всё может сломаться даже на +0.0.1 к версии какого-то из них, потому что авторы гемов тоже привыкли к тому, что bundle install тащит всё с собой, и не особо парятся с обратной совместимостью.

        Ну и да, обновлять каждый бандл нужно отдельно ручками, ибо apt/yum/portage/whateverelse про твой бандл слегка не в курсе.

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

          Один гитлаб тащит полсотни какого-то непонятного кода, компилит что-то, кто его знает что это такое. И вот мне надо всё время обновнять руками этот гитлаб, потому что вдруг в этих зависимостях уязвимость какая-то объявилась. Особым шиком в гитлабе сейчас является зависимость от nodejs (сам гитлаб на руби) для того, чтобы что-то собрать во время установки.

          Делали вот unix, пакетные менеджеры, селинуксы всякие и тут на тебе.
          • 0
            Я думаю nodejs там можно без проблем заменить на therubyracer.
            • +2
              Я не бум-бум в рельсах и руби, так что что-то менять в коде у меня нет большого желания.
            • 0
              Когда говорят про ноду в этом контексте часто имеют ввиду v8. А therubyracer — обёртка над v8. Один из движков для execjs, который для шаблонизации иногда.
              • 0
                Благодарю, но я в курсе.
            • 0
              therubyracer под windows не работает, насколько я помню из своего опыта работы с рельсами в марте этого года. Да и смысла нет в этой замене, даже для Linux. Для работы рельсов с помощью nodejs npm не требовался.
              • 0
                Смысл есть, если Вам не нужен ещё node.js для ruby стека. На windows лучше уж vagrant с Linux машиной.
          • +2
            Делали вот unix, пакетные менеджеры, ...


            … а потом всех утомила ситуация «да боже мой, опять в репозиториях древняя придревняя либа, с которой мой код не работает». На самом деле идея launchpad для решения этой проблемы довольно неплоха, но это только для debian based подходит, насколько я помню.
            • +3
              Это просто хостинг сторонних репозиториев, если я не ошибаюсь.
              • 0
                Технически верно. По факту — надёжный источник актуальных билдов пакетов, собранных автором проекта и в каком-то роде разгрузка для мейнтейнеров основных репозиториев дистрибутивов (собирать каждую актуальную версию каждого пакета — довольно невесёлая задача).
            • +1
              Всех утомила ситуация вида: разрабатываем и собираем с теми библиотеками, что есть в репозитории, только на сервере, т. к. работающее на машине разработчика может не собраться или не заработать на сервере. Куда веселее становится, когда надо это же приложение запустить ещё на новой мажорной версии операционки…
            • 0
              Ну в целом решения два: либо ищем другой репозиторий, которому мы доверяем; либо компилим для себя из сорцов, что, в целом, тоже неплохой вариант.
              • 0
                Ну в целом решения два: либо ищем другой репозиторий, которому мы доверяем

                Довольно сложная задача, на самом деле, когда ты — параноик :)

                Собственно, когда скомпиленного для себя из сорцов становится много, доставлять всё это на пачку серверов становится несколько сложнее. В этих случаях контейнеры — спасение.

                Опять же, здесь ситуация немного отличается от рассматриваемой в статье автором (здесь контейнер делается самим сисадмином/программером/devops'ом, а не качается не пойми откуда).
          • 0
            Гитлаб перестал ставить сам, а стал ставить из deb-пакетов Omnibus GitLab.
            Устанавливать обновления стало гораздо проще.
        • +1
          > рельсоприложение тащит с собой свой Gemfile.lock с прикрученными гвоздями версиями гемов

          Логично.

          > то всё может сломаться даже на +0.0.1 к версии какого-то из них

          Многие следуют semver.org, я больше видел такие проблемы с npm пакетами, например underscorejs.org

          > bundle install тащит всё с собой, и не особо парятся с обратной совместимостью.

          Лучше укажите пример, а то Я не встречал, что бы популярные гемы нарушали semver.org и обратную совместимость между версиями.

          > Ну и да, обновлять каждый бандл нужно отдельно ручками, ибо apt/yum/portage/whateverelse про твой бандл слегка не в курсе.

          ansible/chef/puppet/saltstack for deps + «bundle update» и не забываем про хороший test coverage = тогда никакие апдейты не страшны.
          • 0
            > Многие следуют semver.org

            А ещё больше не следует, в том числе Rails и его библиотеки — в 4.1 и 4.2 сломалось много чего, что работало в 4.0.
      • 0
        Та же фигня с модным нынче rvm — в вашем зоопарке бандлов какой-то гем сломался при переходе на Ruby 2.2, а обновить его не получается, потому что тогда сломается что-нибудь ещё? Ставьте rvm! А то, что при этом придётся отслеживать и обновлять ручками каждый патч-релиз ruby (это если они ещё выходят, а ведь встречаются гемы, которые работают только на 1.8.7, авторы которых вообще забили болт на апдейты). А после обновления (даже с одного патчлевела на другой) не забыть ещё и обновить руками пути к passenger_ruby в nginx.conf или что там у вас вместо сервера.
        • +1
          > Та же фигня с модным нынче rvm

          Ну не нравится rvm — юзайте rbenv, он проще, особенно для production/staging.

          > в вашем зоопарке бандлов какой-то гем сломался при переходе на Ruby 2.2, а обновить его не получается, потому что тогда сломается что-нибудь ещё? Ставьте rvm!

          А как это поможет? Из-за rvm гем неожиданно не заработает на 2.2 :)

          > А то, что при этом придётся отслеживать и обновлять ручками каждый патч-релиз ruby

          java/erlang/golang приходится тоже обновлять. Систему конфигурации должна помочь Вам не делать данную работу руками.

          > это если они ещё выходят, а ведь встречаются гемы, которые работают только на 1.8.7, авторы которых вообще забили болт на апдейты

          Просто не используйте такие гемы. Это уж действительно что то старое.

          > А после обновления (даже с одного патчлевела на другой) не забыть ещё и обновить руками пути к passenger_ruby в nginx.conf или что там у вас вместо сервера.

          Так вот в чем проблема. Я не говорю что так нужно везде, но иногда проще запускать passenger как standalone — тогда обновлять nginx и passenger проще (не нужно морочиться с конфигом nginx при обновлении passenger, они не зависят друг от друга). Так же происходит и при использовании unicorn/puma/etc.
        • 0
          А чем этот процесс отличается от работы с любыми другими пакетными менджерами? И если есть проблема, то где она решена?
    • +2
      Не докером единым, всякие npm, bundle и иже с ними вместо нормальных системных зависимостей качают черт знает что в папку пользователя и это всё культивируется как мейнстрим.
      В подходе npm есть смысл, и смысл этот вот каков: зависимость не обязана быть системною, и она рассматривается как локальная зависимость единственного модуля — того именно, который от неё зависит. При этом разные модули могут требовать разных версий некоторой зависимости — и они получат желаемое, получат благодаря механизму локальной установки зависимостей.

      (Понятно, что этот подход предполагает сильное доверие к репозиторию npm и к Гитхабу, но это ужé другой вопрос.)
      • –1
        Это ужасный подход, по факту у вас может несколько версий одного и того же кода исполняться. Зависимость от версий это очень печально. Прижилось это в npm потому, что люди колбасят что попало не парясь.
        • +2
          К сожалению в реальном мире обратная совместимость библиотек далеко не всегда гарантируется и с этим ничего не поделать: это для любой системы управления пакетами характерно, не только для npm.

          P.S. "люди колбасят что попало не парясь" — отличная фраза. Ей можно описать все состояние индустрии приблизительно годов этак с 70-х :-D
          • 0
            Ага, что лучше, проблемы с обратной совместимостью или вот такой зоопарк версий? npm позволяет не париться насчет версий, тем самым оказывая дурное влияние.
            • 0
              это для большинства пакетных менеджеров характерно, не только npm. Ну а дурное влияние должно компенсироваться разумным подходом :)
    • 0
      Ух, оказалось я не один так думаю. С первого взгляда я вообще не понял, зачем там нужен отдельный пакетный менеджер, и как это может упростить жизнь, ну и вообще не очень подружился с node и npm, хотя вроде как и надо бы, ибо мейнстрим же. Так и живу в неведении, и боюсь притронуться…
  • +9
    Когда-нибудь пробовали сделать обновление безопасности для контейнера?


    А как вы обновляете бинарные пакеты — скачиваете свежие из apt/yum/wtf. То же и с докером — скачиваете новый образ.
    За отутствие цифровой подписи его много и справедливо ругали — но докер привлек много денег и деньги надо отбивать — нету у них времени закрывать баги.
    Ответ прост appc и rocket.

    С докером же правило простое — качай Dockerfile, собирай у себя и толкай во внутренний registry.
    • +1
      Ну не согласен.
      Если я apt (или другой подобной утилитой) закрываю дыру в либе, то она закрывается сразу для всех приложений.
      Более того, я уверен, что если дыру нашли, то её закроют и уверен, что я получаю версию именно от соответствующего маинтейнера, а не дядьки посередине.

      Если я скачиваю новый образ (приложение, etc), то я обновляю лишь соответсвующее приложение (аналогичные дыры в других местах не трогаются), а также вместе с новыми фиксами я получаю новые баги, потому что нет модели выпуска релизов, ориентированной на качество и безопасность.
      P.S. Моё мнение может отличаться от мнения автора оригинального текста.
      • 0
        Ну это же только вопрос времени, сейчас докер это тул для деплоя _своего_ кода. А в перспективе это будет такой же менеджер как apt, и образы будут так же выпекаться в каноникле или еще где то в проверенном месте.
        • +2
          Неизбежный рассвет в социалистической СССР был тоже только вопросом времени.
          Не верю, что всё будет так, как вы говорите.
      • –2
        Такое ощущение, что вы не понимаете, как докер работает.

        Он состоит из слоёв. Первый слой(base image, директива FROM) — обычно ubuntu/debian/centos. Если у вас запущено ХХ контейнеров с одинаковым base image, то при новом запуске контейнера докер делает следующие вещи:
        1. Проверяет, что локальный base image имеет такой же хэш, как и тот, что в репозитории.
        2. Если нет, тогда заново собирает слой, который имеет неверный хэш и все ниже.
        3. Если да, тогда просто запускает из этого слоя.

        Таким образом, для того, чтобы обновить ВСЕ приложения, запущенные на одном base image, вам нужно всего лишь перезапустить контейнеры. Даже apt-get install не придется делать.

        Это при условии, что в base image стоит пропатченная либа. Так как base image собирается в нормальных компаниях автоматически каждые N времени и сразу же после выпуска патча безопасности, то дыры после перезапуска контейнера уже не будет.
        Если вы собираете свой base image, то можете сделать apt-get update и docker pull перед рестартом всех контейнеров.

        ИМХО, вы ищите проблему, которой нет.

        P.S. Докер образ для ubuntu собирают как раз ребята из canoncial. За основу берут cloud-версию убунты(емнип)
        • +1
          Да нет, понимаю в достаточной степени.

          Если у нас один «base image», то проблем нет. Берём и обновляем.
          А если у нас 10 контейнеров не на одном, а на разных «base image»? И находят какую-нибудь большую дырку в общесистемной либе (по типу OpenSSL или Bash). Теперь нужно обновить все 10 образов-то, и с таким объёмом что-то забыть гораздо проще, да и вообще не очень удобно.
        • +2
          Таким образом, для того, чтобы обновить ВСЕ приложения, запущенные на одном base image, вам нужно всего лишь перезапустить контейнеры

          Нет, перезапустить контейнеры будет не достаточно. Потому что слои ссылаются на уникальные идентификаторы образов, которые имеют мало общего с «тэгами», которые мы используем в «FROM».
          Чтобы обновить базовый образ для 10 работающих контейнеров, следует пересобрать образы для каждого из них (docker build), затем удалить все и создать заново. Потому что нельзя сделать restart контейнера, подменив ему идентификатор образа.
          И это не баг, а фича «immutable infrastructure», гарантирующая неизменяемость базового слоя контейнера в процессе его жизни. Конечно, можно зайти через «nsenter» или «docker exec -ti bash» или «ssh» или, боже упаси, напрямую в файловую систему верхнего слоя контейнера на хостовой машине, но это будет не «by design».
          С другой стороны, необходимость пересоздавать контейнеры для обновлений образа это большая боль, сводящая на нет такие красивые концепции, как "--volumes-from" и "--link".
          В итоге, лобая система, используящая Докер более-мение серьезно, обрастает кучей костылей тут и там.

          По поводу цивфовых подписей, Докеры же сделали это в 1.6 и Registry 2.0.
          • 0
            По поводу цивфовых подписей, Докеры же сделали это в 1.6 и Registry 2.0.
            Подписи появились в 1.3 (https://blog.docker.com/tag/digital-signature/), но они дюже странные. На эту тему рекомендую ознакомится со статьёй Docker Insecurity by Jonathan Rudenberg

            В 1.6 (и registry 2.0) появилась возможность ссылаться не на тэг, а на конкретный образ (используя синтаксис namespace/repo@sha256:feffdeadbeef...) Тогда при security update вы можете сообщить пользователям образа в каком именно билде контейнера была исправлена уязвимость и они обновятся на указанный билд, а не тэг, как это делалось ранее.
  • +11
    С другой стороны, вся эта контейнеризация наоборот повышает безопасность.
    Представьте себе квест с апгрейдом версии ОС на тысячах серверов. Это же нужно руками делать, потому что где-нибудь что-нибудь обязательно отвалится. Гораздо проще налить новую машину с новой версией и накатить рабочий puppet/salt/chef.
    Однако, со временем, это начнет обрастать костылями, т.к. какой-либо пакет просто не работает с новой версией. Другой — имеет жесткие зависимости. Третий вообще не пойми что. Использование контейнеров позволяет, во-первых, обновить ВЕСЬ кластер простым рестартом контейнера(он скачет новый базовый образ), во-вторых, не беспокоиться о зависимости(стоят только нужные для запуска именно этого приложения либы), в-третьих, дают изоляцию, в-четвертых, дают единую точку для управления конфигурацией приложения(докер файл/рокет манифест/другое), в-пятых, единство окружения(зайти в контейнер и вручную что-то поправить гораздо сложнее, чем на привычный сервер).
    По-настоящему, проблема не в технологиях — они лишь инструмент, а в людях. Это как обвинять Эйнштейна, что он убил жителей Нагасаки.
    Но я понимаю, о чем вы говорите и согласен, что проблема есть — зачем нанимать дорогого сисадмина, когда я сам могу скачать бинарник из интернета. Зачем делать правильно, когда и так всё работает.

    Думаю, что такая проблема появилась во всех сферах жизни. Чтобы сделать сайт не нужно нанимать программиста полгода, ведь есть WordPress. Безопасность? Авось пронесет, да и когда это будет, а бизнес требует сайт уже сейчас.

    Резюмируя, скажу, что люди сами себе злобные буратино.

    P.S. Большого бума не будет — просто произойдет деградация отрасли. И это уже происходит. Например, с появлением в сфере ИТ «эффективных менеджеров», которые ну ничего не понимают, т.к. только закончили ВУЗ, изменился поход к написанию ПО — вместо качественного продукта нужно выпустить продукт быстро и с множеством фич.
    • 0
      С вами согласен, если использовать контейнеры так, как вы написали, то вопросов нет — хороший инструмент в данной ситуации.
      Проблема именно в концепции «приложений», которым нельзя доверять, и вообще к соответствующему способу дистрибуции ПО.
      P.S. Моё мнение может отличаться от мнения автора оригинального текста.
  • +1
    С другой стороны, вся эта контейнеризация наоборот повышает безопасность.
    Представьте себе квест с апгрейдом версии ОС на тысячах серверов. Это же нужно руками делать, потому что где-нибудь что-нибудь обязательно отвалится. Гораздо проще налить новую машину с новой версией и накатить рабочий puppet/salt/chef.
    Однако, со временем, это начнет обрастать костылями, т.к. какой-либо пакет просто не работает с новой версией. Другой — имеет жесткие зависимости. Третий вообще не пойми что. Использование контейнеров позволяет, во-первых, обновить ВЕСЬ кластер простым рестартом контейнера(он скачет новый базовый образ), во-вторых, не беспокоиться о зависимости(стоят только нужные для запуска именно этого приложения либы), в-третьих, дают изоляцию, в-четвертых, дают единую точку для управления конфигурацией приложения(докер файл/рокет манифест/другое), в-пятых, единство окружения(зайти в контейнер и вручную что-то поправить гораздо сложнее, чем на привычный сервер).
    По-настоящему, проблема не в технологиях — они лишь инструмент, а в людях. Это как обвинять Эйнштейна, что он убил жителей Нагасаки.
    Но я понимаю, о чем вы говорите и согласен, что проблема есть — зачем нанимать дорогого сисадмина, когда я сам могу скачать бинарник из интернета. Зачем делать правильно, когда и так всё работает.

    Думаю, что такая проблема появилась во всех сферах жизни. Чтобы сделать сайт не нужно нанимать программиста полгода, ведь есть WordPress. Безопасность? Авось пронесет, да и когда это будет, а бизнес требует сайт уже сейчас.

    Резюмируя, скажу, что люди сами себе злобные буратино.

    P.S. Большого бума не будет — просто произойдет деградация отрасли. И это уже происходит. Например, с появлением в сфере ИТ «эффективных менеджеров», которые ну ничего не понимают, т.к. только закончили ВУЗ, изменился поход к написанию ПО — вместо качественного продукта нужно выпустить продукт быстро и с множеством фич, т.к. для менеджера «горят сроки» или «у конкурента есть фича» более понятные фразы, чем «нужно всё переписать, потому что тут возможен race condition».
    • +2
      Ну и дополню себя, что все эти bower и npm создалось в первую очередь для удобства разработки, программистами для программистов. Сисадмин должен понимать, что это не подходит для продакшна. А менеджер, что развитие инфраструктуры с самого начала окупит себя в долгосрочной перспективе.
      В крупных компаниях, где я бывал, чаще всего разработчики варятся отдельно от сисадминов и делают ровно так, как им удобно и быстро, чтобы войти в рамки KPI. Сисадмины же — не более, чем обслуживающий персонал и чаще разгребают за менеджерами(например, срочный и не проверенный релиз) и программистами(работает только на этой версии либы? поставлю жесткую привязку. Нужно Х? Добавлю костыль в init.d или postinstall), чем занимаются развитием инфраструктуры или защитой своих интересов.

      Так что, подпись пакетов — это меньше зло из существующих.
  • 0
    А в чём проблема сборки хадупа? mvn + cmake (для native extensions). У мавена довольно серьезная проблема с тем, что часть репозиториев отвечает по http и jar'ники не подписаны. Хотя тот же central стал в новых версиях мавена работать по https судя по логам.
    • 0
      Ну так как написано в посте: проблема в инструментах для сборки, а также именно в мавене с неподписанными пакетами.
      Собственно автор имеет отношение к debian, и он как раз пишет, что очень очень сложно запаковать hadoop в пакеты с достаточным уровнем качества (софт, который во время сборки выкачивает неподписанный код из интернета, — это очень далеко от стандарта качества дебиана).
      P.S. Моё мнение может отличаться от мнения автора оригинального текста.
      • 0
        Apache релизит в central, central, вроде, проверяет pgp-подписи. То, что мавен не проверяет подписи (только хэши) — вопрос вторичный, сейчас он вполне работает по https.

        Мавен, в первую очередь, гонится за детерминированной сборкой. И зависеть от WoT текущего пользователя не хочет.
      • 0
        Юзайте ж Artifactory какой-нибудь, держите там проверенные вещи.
  • +3
    В целом я согласен, но сборка из исходников тоже не дает 100% эффекта без аудита всех этих исходников (а это нетривиальная задача при таком количестве зависимостей)… Комьюнити, ревьюеры — через них конечно многое не протащишь (в плане АНБ и тп), но все равно это не является невозможным.
  • +5
  • +4
    Зато протащить свой код в официальные репозитории Debian/Ubuntu — это тот ещё геморрой. У меня знакомый почти год добивался, чтобы его библиотека туда попала. Далеко не все могут проявить недюжинное упорство, а наработки нужны здесь и сейчас. Чтобы опубликовать новую библиотеку в Maven Central человеку, который никогда этого не делал, достаточно одного вечера, и после этого весь мир может его использовать. Чтобы обновить — достаточно десяти минут. Конечно, никакого серьёзного ревью нету, всё по большому счёту на взаимном доверии. Но работает же. По-моему, прогресс важнее повальной паранойи, что вас взломают.
    • +3
      Под любой вменяемый дистрибутив собрать новый пакет не составляет особого труда для профпригодного админа.
      Поднимаются те же виртуальные сервера, делятся на группы по назначению и выкатываются те пакеты и тех версий, в дополнение к базовой системе, какие надо. Образ того же докера тоже нужно собирать и обычно из тех же пакетов…

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

      А вот с подписями пакетов это беда, причём очень и очень много где.
    • +3
      А свое зеркало поднять влом? Да и ланчпад же есть, зачем сразу в источники?
      • +1
        Зачем сразу «влом»? Вот написал я полезную библиотеку для других разработчиков. Кто будет вводить её в зависимости, если она ставится только с моего никому не известного зеркала? Не каждый и на ланчпад завяжется.
    • 0
      У панайони есть разные уровни, один из максимальных — что все уже давно взломано в пух и прах где ни будь на уровне базовых криптобиблиотек или принципиальных алгоритмических уязвимостей. Единственное ограничение — подобные уязвимости нельзя эксплуатировать широко, так как разрабатывать новые крайне дорого.

      На то она и паранойя, чтобы воспринимать возможное как реальное.
      • 0
        Но помогла ли концепция web of trust от серьёзных взломов последних лет? И OpenSSL, и bash ставились из надёжных и доверенных источников.
    • +1
      Все здорово до одного момента, пока это доверие не начнет кто то эксплуатировать, и размещать в репозитарий недобросовестный код.
  • 0
    >> Maven, ivy и sbt — это утилиты для скачивания неподписанного кода и запуска его на вашем компьютере.

    Не совсем так. Это утилиты для сборки java/scala… и вообще по-моему уже любого кода.
    В случае maven можно сделать спокойно review repositories и убрать все опасные из pom файла. Кстати код в central maven подписывается.

    Для сборки hadoop насколько мне известно достаточно сделать git pull и запустить mvn clean install. И установить получившийся бинарник.

    • 0
      Там ещё профили нужные надо включить. Например, статья pravinchavan.wordpress.com/2013/04/14/building-apache-hadoop-from-source
      • 0
        Там есть дефолтные профили, разве их недостаточно для сборки?
        • 0
          Не знаю, я хадуп сейчас не использую и, тем более, не вижу смысла его пересобирать из исходников — ноут раскаляется ,)

          Задач, требующих патченного хадупа обычно у людей либо не возникает, либо не представляет никакой особой сложности, когда уже требуется.
    • 0
      Ivy (и SBT соответственно) тоже используют подписанные jarы по умолчанию
  • +13
    У автора очень странное впечатление о докере. Такое ощущение, что он считает, что живые люди только и делают что берут образы докер контейнеров из разных мест и лихо запускают это в своем пордакшене. Во первых, этих «разных мест» в общем то и нет. Есть registry hub из которого конечно можно скачать этот самый образ, но можно и посмотреть, что он там собирает или, что совсем несложно, собрать его у себя.

    Лично я смотрю на hub как на место где подсмотреть как построить контейнер для той или иной нетривиальной системы и использовать это знание для построения своих собственных, деплоющих образы в свой собственный registry.

    Что касается обновлений — я совсем не понимаю о чем он говорит. Во первых, все нормальный контейнеры disposable, и получить новый, со всеми фиксами — это либо docker build либо docker pull. Ну а если вдруг очень хочется/надо обновить нечто по старинке, то «docker exec apt…» никто не помешает сделать.
    • +5
      Зашел в статью, только чтобы поискать ответ Умпутуна.
      Нашел.
      • 0
        Вообще подобный срач будет ещё не раз возникать из-за не понимая вопроса(контейнеров, процессов и большого «бутерброда» вокруг всего этого)
        Docker hub — для ленивых и доверяющих сообществу программистов. Не нравится, не доверяешь — создавай свой registry, репозиторий/дистрибутив/образ — как тебе нравится, проверяй пакеты, систему на отсутствие закладок Cам, своими силами и руками — никто в этом тебе не мешает(кроме конечно времени).
        Так как докер это: 1 процесс=1 контейнер — то там и проверять легче гораздо. Никаких лишних процессов.

        Первый раз услышал про docker как раз с radio-t :) спасибо им за это.

        p.s. И да, Docker — это не безопасно, это просто Удобно.
      • +2
        Выпуски radio-t за последние пару лет — это сплошной ответ Умпутуна на критику докера…

        А я вот зашел посмотреть какие еще аргументы придумали сисадмины, что бы их пожалели. Заголовок больно желтушный. В таком стиле можно целую серию статей выпустить: «Печальное состояние сисадминов в постмайнфрейновую эпоху персоналок», «Печальное состояние сисадминов в эпоху, когда компьютерной грамоте стали учить не только инженеров, но и детей в школах», «Печальное состояние сисадминов в эпоху безлимитного интернета», «Печальное состояние сисадминов в эпоху ухода в облака»… И каждый раз можно рассказывать, как стало все плохо, слабоуправляемо и несекьюрно. А можно идти в ногу со временем, изучать все слабые места современных архитектур и вырабатывать регламенты для минимизации рисков.
        • +1
          > эпоху, когда компьютерной грамоте стали учить не только инженеров, но и детей в школах

          Угу, а потом эти компьютерно грамотные дети вырастают, приходят на работу, видят окно с текстом на чистейшем русском и одной кнопкой и звонят сисадмину: «помогите, тут что-то написано и ничего не работает!»
          • 0
            Это вы уже ради флейм на вентилятор начинаете набрасывать. Ведь мы прекрасно знаем, что бабушки и дедушки, которые всю жизнь проработали на заводе, отлично себя чувствуют с современной техникой и просиживают часами в одноклассниках. На эту тему у Уральских пельменей есть очень показательная сценка — youtu.be/2jNBvcYmeAM

            А вот те, кто делает круглые глаза и вызывает сисадмина при каждом алерте делятся на две категории:
            1) Матответственные, которым за малейшую ошибку снимут несколько месячных зарплат. Пусть уже сисадмин будет крайный — это он запорол подготовку отчетности и компания влетела на штрафные санкции.
            2) Саботажники. И не важно специальные вредители на премиальных от конкурента, или просто лентяи, они просто ищут причины не работать. И школьное образование тут не при чем.
  • +3
    Прочитал пост, комментарии и заплакал. Тут всё, о чем я думал и переживал на счет упомянутых продуктов.
    Обнимемся!
  • 0
    Непонятно чем именно контейнеры виноваты. Никто не мешает собрать контейнер самому, используя только доверенный код и\или подписанные бинарники. Да, контейнеры легче деплоить и поэтому все их и используют, но что вы предлагаете в качестве альтернативы — по 1000 раз повторять одни и те же шаги по сборке стандартных вещей, тратя время попусту и ошибаясь на ровном месте?
  • +2
    Вопросы, поднятые в топике, на мой взгляд, резонны. Единственное, что проблема не только и не столько в докере, сколько это вообще вопрос доверия в интернете. Мы устанавливаем пакеты из бинарных дистрибутивов, устанавливаем ОС, загружаясь с образа, скачанного из интернета, устанавливаем всякие плагины (Flash, например), взятые из интернета, бинарные драйверы видеокарт, скачанные с сайтов производителей. Даже если всё это подписано какими-то подписями, знаем ли мы этих людей, доверяем ли мы им? Даже собирая Linux from scratch, мы используем бинарник компилятора, загруженное ядро операционки. Есть ли гарантия, что они не встроят в компилируемый код бэкдор? Здравствуй, паранойя.

    Если честно, я не знаю, как вести себя в условиях недоверенной среды. Не доверять всем — слишком дорого. Я могу написать свой компилятор C, провести аудит всего кода, который используется в продакшне, но это настолько огромная задача, что не хватит жизни. Для себя я использую такую формулу: если уж использовать чужие решения, то только те, которыми пользуется максимально большое число людей (популярные дистрибутивы, популярные пакеты, в докерхабе — только базовые контейнеры от самого докерхаба), чтобы минимизировать риски. А всё остальное писать самому.
    • 0
      Нужно учиться работать с рисками.
      Оценивать, уменьшать, разделять и т.д.
      Не зная теории, мы и так интуитивно это делаем.
      «Телефон в один карман, ключи/открывашку в другой», «бекапы на разных серверах», «разные почтовые ящики для работы и дома».
    • +1
      Ещё можно повсюду внедрять подход «воспроизводимости». Тоесть собрав пакет у себя на машине (используя те же версии соответствующего ПО) вы должны получить бинарно идентичный пакет. Казалось бы, что так обычно и должно быть, но в реальности сборка вполне может зависеть от времени, настроек часовых поясов, и т.д.

      Вот дебиан, кстати, над этим работает («Некоторые даже работают над воспроизводимыми сборками» — это как раз автор про дебиан говорит).

      Если интересно можете прочитать про воспроизводимость в дебиане здесь.
  • +1
    По существу, подход Docker'а состоит в скачивании неподписанных бинарников, запуске их, и надежды, что они не содержат бакдоров для сети вашей компании.

    Что мешает брать образ контейнера с автоматической сборкой из общественно доступного репозитория, где Dockerfile имеет только apt-get install и cp/mv/cat/sed команды? Docker не проблема, проблема в тех, кто его неправильно использует. К тому же, там появилась проверка цифровых подписей, хоть и в тестовом виде.
  • 0
    Я все как-то был больше юзером, чем админом. А недавно решил развернуть новый open source от Onlyoffice. Сперва героически попробовал всё это с гитхаба собрать, понял, что не хватает скиллов. И тут мне помог именно Docker — взял отсюда и спокойно развернул, теперь вовсю тестирую, что такого нового они понасовали. Есть вариант проще, но это, конечно, не олдскул и, возможно, не совсем безопасно, но меня как простого пользователя устраивает. Так что контейнерам пока не отказать и этот пример это доказывает…
  • +3
    Философское: невозможно создать дыру в пустоте, невозможно допустить security-ошибку в телнете без авторизации. Поскольку мы не умеем бороться с security-проблемами, то мы просто изменяем среду исполнения так, чтобы проблема более не выделялась на фоне, то есть отсутствовала.

    Очевидно, что при таком деплое примерно 50% ошибок в безопасности в софте оказываются неактуальными — их эксплуатация для взломщика будет более тяжёлой и затратной, чем более простые методы проникновения. Таким образом достигается святой грааль безопасности: хакеру выгоднее НЕ использовать уязвимость, чем использовать.
  • +3
    Всё верно, нужно устанавливать только сборки от ФСБ(КГБ)
  • +1
    Спасибо за статью! Думаю вы выразили мнение очень многих!
  • +1
    А теперь шах и мат www.opennet.ru/opennews/art.shtml?num=42322
    Первоисточник www.banyanops.com/blog/analyzing-docker-hub
  • 0
    Я думаю, дело в том, что большинство людей исползующих этот стэк (ну да stack) технологий, не заботит уязвимость, т.к. крутится это всё в виртуальной сети, поднимается на один раз и не на долго.

    Атакующий может урвать кусок плохоструктурированной информации, в лучшем случае.

    Если же безопасность таки критична — всегда можно собрать свой репозиторий. Вопрос в цене. Для большинства случаев достаточно поделия из фекалий и сучьев.
  • +1
    чтобы включить бакдоры от АНБ
    Паранойя — страшное дело… Включайте свои мозги и поменьше поддавайтесь на пропаганду, иначе можно дойти до жизни в подземном бункере с алюминиевой шапочкой на голове, чтобы уж наверняка никто вас не подслушал/не увидел/не обнаружил.

    Если же говорить по теме, то да — контейнеры «расслабляют» и нужно понимать, где можно использовать распространяемые в интернете контейнеры, а где нельзя.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.