Сформулируйте вопрос / Поставьте проблему. Выделите объекты, важные для подготавливаемого объяснения.
К разрабатываемым в компании приложениям предъявляются требования по работе с уязвимостями, в частности, что нужно своевременно устранять критические уязвимости в эксплуатирующихся версиях. Уязвимости могут быть как в пакетах операционной системы, так и в библиотеках, используемых приложениями. Приложения упаковываются в образы контейнеров, и для этого в компании поддерживаются базовые образы, которые и содержат операционную систему с пакетами.
Для поставки базовых образов была проделана следующая работа:
- базовые образы автоматически сканируются на уязвимости и пересбираются по расписанию после публикации баз уязвимостей
- из образов убраны лишние пакеты
- это уменьшает attack surface (меньше уязвимостей и частота пересборки)
- дополнительно это уменьшает размеры образов и нагрузку на инфраструктуру для их хранения и скачивания
Можно сказать, что проблема поставки базовых образов без уязвимостей решена, но ситуация выглядит как лечение симптомов, а не причины. Зачем добавлять в образы пакеты (вендор образов думает скорее о простоте и универсальности применения), которые не нужны, чтобы потом закрывать в них уязвимости?!
Получается, что пакеты приводят к:
- больше уязвимостей, которые надо закрывать
- больший размер итоговых образов и лишняя нагрузка на инфру
- больше attack surface
- лишние пакеты объективно не нужны в итоговых образах для работы приложений в продакшне
Есть семейство образов, которые называются distroless - они якобы не на базе каких-то дистрибутивов Linux, а собираются с нуля, содержат минимально необходимое количество пакетов, в пакетах оперативно устраняют уязвимости. Поэтому возникла идея перевести все базовые образы на distroless для устранения этих недостатков.
Получается, что вопрос можно сформулировать таким образом: как мы можем перевести все базовые образы на distroless?
Найдите 2-3 гипотезы (варианты объяснения).
- перевести базовые образы на dhi (Docker Hardened Images)
- перевести базовые образы на chainguard
Начните доэкспериментальную аргументацию – выявите допущения, начните искать причинно-следственные связи, важные для вашего объяснения в контексте выдвинутых гипотез.
Общие допущения:
- перевод базовых образов на distroless оправдан (в том числе по стоимости)
- у компании будет доступ к вендорским distroless-образам
- поддерживаются разнообразные версии нужных языков программирования и других инструментов
- разрабатываемые приложения будут совместимы с distroless-образами
- формат описания distoless-образов такой же простой и понятный
- сборка distoless-образов такая же простая и понятная
- добавлять новые пакеты в образы будет так же легко, как и сейчас, команды разработки приложений смогут продолжать это делать сами
- пакеты будут так же автоматически обновляться при пересборке, за счёт чего устраняются уязвимости
Причинно-следственные связи:
- Вендоры поставляют готовые образы с разными версиями ЯП и инструментов - то есть можно использовать их или попробовать собрать свои аналогичные.
- У вендоров есть документация по сборке своих образов, так что мы сможет это сделать.
- Вендоры предоставляют платные услуги по сборке кастомизированных образов, но можно реализовать её у себя (почти бесплатно).
- Типовое приложение не предъявляет каких-то особых требований к образам (без дополнительных пакетов), поэтому должно работать и с distroless. Большинство приложений типовые.
Эссе о начатом исследовании с примерами в разработанном формате написано и размещено в клубе Мастерской. Для подробного описания результатов вашей работы начните разработку табличного формата описания (в соответствии с методом, изученным вами в разделе 11 «Построение онтологического описания»). Вы продолжите выполнения этого задания после изучения следующих разделов.
Дальше получилась история в духе “лучшее - враг хорошего”.
В процессе проверки гипотез оказалось, что есть допущения, которые я не учёл, и которые усложняют реализацию. Например, вендоры фиксируют версии пакетов в образах для воспроизводимости сборки, поэтому просто пересобрать образы недостаточно, чтобы пакеты в них обновились - нужно делать свои и указывать там пакеты по-другому. Если нужно добавлять свои пакеты в образы, то тут тоже оказалось не так просто: не всегда понятно, как именно указать пакет, при сборке вылезает ошибка, что такого пакета нет. Пакеты у разных вендоров могут отличаться или отсутствовать. В одном случае для установки небольшой утилиты пришлось поставить огромный пакет, что раздуло образ в разы больше, чем в исходном варианте, где в дистрибутиве ОС пакет разделили на несколько частей поменьше.
Заодно в процессе добавления дополнительных пакетов подсветился момент, что собирает и предоставляет образы одна команда, а потребляет - другие. Если нужно собрать образ со специфическими дополнительными зависимостями, то команде потребителю сразу нужно обращаться к команде поставщику, чтобы та сделала целый новый образ - то есть их количество может кратно вырасти. Рассчитывать, что команды-потребители смогут собрать образы сами себе как раньше, не приходится, а возможности поставить дополнительные пакеты в своём образе в distroless-вариантах нет.
Ещё и не все нужные образы доступны бесплатно, а ввязываться в платную историю, когда завтра могут закрыть доступ, не вариант.
В итоге обратился к LLM за идеями, что можно сделать в такой ситуации, чтобы минимальными усилиями (а не превращаясь в полувендора distroless базовых образов) внедрить distroless-образы, и появились дополнительные гипотезы:
- внедрить типовые базовые образы для типовых приложений, а специфические оставить на текущем варианте, где команды сами смогут их кастомизировать, переключиться на старые базовые образы достаточно просто
- проблема оптимизации размеров (выигрыш будет уже не в разы, как при первом подходе) и устранения уязвимостей в базовых образах решена на приемлемом уровне, можно ничего не делать
Пока что я остановился в проработке вопроса, когда стало понятно, что текущую реализацию не обязательно улучшать ради улучшения, но в случае необходимости вернуться к вопросу, есть гипотеза 3, которую можно будет взять в работу.