Стоит ли использовать Distroless-образы для контейнеризации Java-приложений

Май 06, 2024

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

В этой статье разберем, что такое Distroless-образы, в чем их особенности, и подходят ли они для контейнеризации Java-приложений.

1. Что такое Distroless
2. Как язык программирования влияет на итоговый размер Distroless-образа
3. Безопасность Distroless
4. Какое решение наиболее оптимально для контейнеризации Java-приложений

Что такое Distroless

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

Стоит отметить, что хотя Distroless и позиционируются как «образы, не содержащие ОС», это не совсем так. Настоящие Distroless-образы можно получить, если использовать в файле Dockerfile директиву FROM scratch. Но такие образы можно использовать только с элементарными статически-линкованными приложениям. Для корпоративных приложений они не подходят, поскольку не содержат важные компоненты, включая сертификаты для настройки TLS, libc для динамически-компилируемых языков (например, Java) и пр.

Поэтому популярные Distroless-образы все-таки содержат Linux-дистрибутив, но сильно урезанный, без менеджера пакетов, shell и прочих привычных компонентов ОС. За счет этого достигается уменьшение размера контейнерного образа, но при этом могут возникнуть другие проблемы:

• Distroless-образы сложно отлаживать, так как у них нет доступа к shell. Для отладки Distroless придется внедрить в рабочий процесс дополнительные решения, такие как эфемерные контейнеры (при условии, что вы работаете с Kubernetes).
• Поскольку выбор готовых Distroless-образов ограничен, велика вероятность того, что они будут несовместимы с вашим приложениям. Добавить дополнительные пакеты сложно из-за отсутствия менеджера пакетов, а чтобы самостоятельно конфигурировать Distroless, нужно очень хорошо разбираться в технологии.

Как язык программирования влияет на итоговый размер Distroless-образа

От языка программирования зависит, какие компоненты ОС понадобятся приложению для корректной работы. Следовательно, размер Distroless-образа будет сильно зависеть от того, программируете вы на Go или Java. Поясним на примере самых популярных Distroless-образов от Google:

• gcr.io/distroless/static-debian12 размером около 2 МБ содержит ca-сертификаты, timezone-данные, etc/passwd и папку /tmp. Такой образ подходит для статически-скомпилированных приложений (например, на Go или Rust), которым не требуется libc.
• gcr.io/distroless/base-debian12 размером около 17 МБ содержит все компоненты static плюс glibc, libssl и openssl. Такой образ уже можно использовать с программами на динамически-компилируемых языках, но если код компилируется GCC, потребуются дополнительные компоненты.
• gcr.io/distroless/cc-debian12 размером около 20 МБ содержит все компоненты base плюс библиотеку libgcc1 (линковка с которой обязательна для GCC-скомпилированного кода) с зависимостями. Но что делать с приложениями на базе интерпретируемых языков или языков, использующих VM (таких как Python и Java)?
• gcr.io/distroless/java17-debian12 размером около 210 МБ содержит базовый Linux-дистрибутив и OpenJDK.

Таким образом, размер итогового Distroless-образа для Java-приложений не будет отличаться от размеров стандартного контейнера, но взамен разработчики могут столкнуться со сложностями отладки и конфигурации, описанными выше.

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

Безопасность Distroless

В некоторых случаях не столько важен размер контейнера, сколько его безопасность. Считается, что безопасность Distroless-образов обеспечивается за счет малого количества компонентов, т.е. уменьшенной поверхности атаки.

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

Хотя Distroless-образы содержат крайне урезанный Linux-дистрибутив, это не является гарантией безопасности по нескольким причинам:

• Linux-дистрибутив в Distroless все равно есть, а значит, он может содержать известные уязвимости (CVE).
• Distroless основаны на Debian и обновляются в соответствии с графиком обновлений этого дистрибутива. Поскольку Debian — это опенсорсный проект без коммерческой поддержки, в случае обнаружения проблемы безопасности или бага необходимо оставить заявку и ждать патча от сообщества. Быстрое решение проблемы никто не гарантирует.
• Невозможно использовать один Distroless-образ для всех рабочих процессов, что затрудняет унификацию ПО и стандартизацию процессов, способствующих повышению общей безопасности ИТ-инфраструктуры.
• Не только Linux, но и другие компоненты, необходимые вашему приложению, могут быть связаны с рисками безопасности. Distroless-образ для Java-приложений содержит среду исполнения Java, основанную на коде OpenJDK, но неизвестно, насколько регулярно она обновляется.

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

Какое решение наиболее оптимально для контейнеризации Java-приложений

Как видите, Distroless-образы — не самое оптимальное решение для уменьшения Java-контейнеров. Однако уменьшить контейнерные образы можно самостоятельно:

• Используйте легковесный Linux-дистрибутив, например, Alpine или Axiom Linux. Базовый образ этих дистрибутивов на основе musl libc весит всего около 5 МБ, при этом необходимые библиотеки можно легко добавить с помощью менеджера пакетов. При это у Axiom Linux есть версия с glibc, которая больше подойдет разработчикам, до этого использовавшим glibc-дистрибутив, поскольку им не придется решать проблемы с совместимостью реализаций библиотеки C.
• Используйте JRE вместо JDK для деплоя или jlink для создания кастомного образа JDK, содержащего только библиотеки, необходимые вашему приложению.
• Сведите к минимуму количество слоев Docker-образа и используйте полезные Docker-инструменты (более подробно о них вы можете почитать в нашей предыдущей статье).

Что касается повышения безопасности контейнеров, необходимо регулярно обновлять программные компоненты, лежащие в основе контейнера, и устанавливать пакеты только из проверенных источников. За отсутствием CVE также помогает следить перечень программных компонентов (SBOM).

Разработчики корпоративных приложений могут воспользоваться Axiom Runtime Container Pro, решением на базе доверенной среды исполнения Axiom JDK Pro или Axiom JDK Certified (сертифицированной ФСТЭК по 4 уровню доверия (УД) и легковесного Axiom Linux от российской команды Axiom JDK.

Axiom Runtime Container Pro позволяет:

• Уменьшить размер итогового контейнерного образа за счет Axiom JDK Pro Lite, версии Axiom JDK Pro, оптимизированной для облачной инфраструктуры, и легковесного дистрибутива Axiom Linux.
• Повысить безопасность ИТ-инфраструктуры благодаря использованию сертифицированных контейнеров и регулярным обновлениям среды исполнения Java и Linux-дистрибутива и техподдержки от команды Axiom JDK Pro в режиме 24/7.
• Выполнить требования законодательства по импортозамещению ПО, поскольку решение входит в Реестр Российского ПО, а значит, может применяться в финтехе и на объектах КИИ.

Если вы хотите узнать больше о Axiom Runtime Container Pro, свяжитесь с нами, и наши инженеры ответят на все ваши вопросы.