Возраст часто ассоциируется с утонченностью: вино, сыр, а иногда и люди с возрастом становятся лучше. Но в мире корпоративных ИТ-систем все наоборот. Старое железо и ПО зачастую теряют актуальность, становятся обузой в техническом плане или, хуже того, ослабляют безопасность. С расцветом Linux-контейнеров как функциональной основы цифровой трансформации пагубные последствия старения становятся только ярче и острее.

Утрируя, можно сказать, что в плане старения контейнеры – не вино, а молоко. Молоко фигурирует в массе кулинарных рецептов, от выпечки до соусов, но если оно старое или прокисло – блюду конец. Точно так же и с контейнерами, особенно сейчас, когда они стали ключевым компонентом решений, работающих в продуктивных средах  – «прокисший» контейнер может дискредитировать самую многообещающую разработку.

Для контейнеров старость наступает уже через несколько недель или, в крайнем случае, месяцев. За это время накапливаются уязвимости, патчи и обновления, без которых контейнерное приложение рискует утратить стабильность и стать непригодным для использования в продуктивной среде. В сложных корпоративных ИТ-средах безопасность системы определяется безопасностью ее самого слабого звена, и устаревший контейнер может стать той брешью, через которую злоумышленник проникнет в систему.

В марте 2018 года компания Tenable, занимающаяся кибербезопасностью, проанализировала несколько тысяч контейнерных образов в репозитории Docker, созданных участниками сообщества, и обнаружила, что в среднем они содержат по 40 уязвимостей. Что еще хуже, 34% этих уязвимостей относятся к разряду критических, типа Heartbleed или Shellshock. Применять такие контейнеры, значит собственноручно закладывать бомбу под безопасность, возвращая в систему уязвимости, для которых уже давно разработаны и выпущены исправления.

Вероятно, возникнет вопрос: как организовать омоложение стареющих контейнеров? Ответ: не надо этого делать.

Старение контейнеров – это нормально

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

К контейнерным рабочим нагрузкам надо относиться как к крупноузловой сборке: если с компонентом что-то не так, его не чинят или дорабатывают, а меняют на другой, новее и лучше. Но как узнать, какие именно контейнеры содержат устаревшие компоненты или больше не отвечают требованиям по каким-то иным причинам? При всей открытости лежащих в основе Linux-контейнеров технологий Open Source, сами контейнеры непрозрачны. Из-за большого количества сопутствующих метаданных и вспомогательных технологий бывает трудно понять внутреннее устройство контейнеризованного приложения и, что важнее, оценить возраст всех его внутренних компонентов.

Безопасность контейнеров: системный подход вместо разовых работ

Обеспечение безопасности, особенно контейнерной безопасности, невозможно без наличия отлаженной системы (или хотя бы экосистемы). Прежде всего, при сборке контейнеров должны соблюдаться все соответствующие требования безопасности — и это только начало. Создавая контейнерные приложения, разработчик, будь то программист-одиночка или софтверная компания, должен принять все необходимые меры для того, чтобы приложение не содержало известных уязвимостей на момент выпуска, как, впрочем, и при сборке традиционных установочных пакетов.

Когда приложение попадает в руки специалистов по эксплуатации ИТ-систем, они обязаны задействовать все надлежащие средства защиты на уровне не только контейнеров, но и хоста контейнеризации. Безопасность контейнерного стека определяется его самым слабым звеном. Поскольку контейнеры используют ядро операционной системы хоста, имеющиеся в ней уязвимости могут породить снежный ком проблем безопасности на этапе развертывания.

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

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

Важность правильного выбора контейнерной платформы

Помимо возраста контейнеров конечные пользователи часто недооценивают важность того, что лежит в их основе – операционной системы. Несмотря на то, что контейнеры «содержат» только необходимые для их работы компоненты ОС хоста, все они используют одно общее ядро. Каждый Linux-контейнер имеет базовый слой, который находится на уровне ОС Linux, поэтому любой разработчик, распространяющий ПО в виде контейнерных образов, распространяет и компоненты Linux. Чтобы такие контейнеры можно было безопасно использовать в режиме промышленной эксплуатации, эти компоненты не должны содержать известных уязвимостей. Если же ОС сама будет иметь такие уязвимости, это поставит под угрозу безопасность всей контейнерной среды, независимо от качества самих контейнеров.

Контейнерная платформа, построенная на основе проверенных технологий корпоративного уровня, помогает решить описанные проблемы за счет единого технологического базиса. Помимо более безопасного и стабильного фундамента такая платформа должна предоставлять функционал Kubernetes для оркестрации контейнеров, автоматизированного развертывания и отката образов, а также работы в условиях мультитенантности. Кроме того, ей неплохо иметь механизмы и инструменты для управления жизненным циклом контейнеров, работы с сетями, хранилищами и реестрами, ведения журналов событий и решения целого ряда других задач, иначе говоря, такая платформа не должна быть односторонней. Совместив эти требования и пожелания, можн получить единую доверенную платформу для реализации контейнерных инициатив и эффективной промышленной эксплуатации контейнеризованных приложений.

Как упорядочить хаос

На первый взгляд, с контейнерами не должно быть особых сложностей, ведь это всего-навсего приложение или процесс, упакованный в один пакет вместе со всеми необходимыми зависимостями. Но в корпоративных средах все не так просто. Как уже говорилось, вокруг каждого контейнера образуется масса метаданных, начиная с того, кто и когда его создал, и заканчивая тем, из какого реестра он был загружен и когда был развернут. Примерно, как упаковочный лист на физический транспортный контейнер, но более развернутый и детальный.

Анализ и сопоставление метаданных требует серьезных усилий, особенно когда контейнеров много, поэтому ими часто пренебрегают. И зря, поскольку важность этой информации трудно переоценить  – без нее легко не заметить, что в контейнеризованном приложении нет важного обновления или, хуже того, там есть устаревшие и потенциально уязвимые компоненты. Однако если организация разрабатывает и регулярно разворачивает и переразворачивает тысячи контейнеров, она неизбежно приходит к пониманию того, что риски безопасности контейнеров надо оценивать на систематической основе. Однако это не обязательно делать самостоятельно. Например, существует индекс безопасности Container Health Index, наглядно ранжирующий контейнерные образы по «степени свежести» на связанных с ними метаданными. Индекс строится с учетом возраста контейнеров, отсутствия важных исправлений безопасности и множества других факторов в области безопасности и разработки решений корпоративного класса на основе технологий open source, которые не только позволяют наглядно контролировать степень безопасности контейнерных приложений, но и помогает дополнительно повысить безопасность на всех уровнях контейнерного стека.

Ларс Херрманн — руководитель направления Workload Strategy for Cloud Platforms, компания Red Hat.