Контейнеры Rootless режим контейнера Зона ответственности: Printum + Заказчик / Интегратор Коротко: Основные контейнеры Printum запускаются от непривилегированных пользователей и не требуют запуска процессов внутри контейнера от root. Поддержка rootless-режима контейнерного рантайма зависит от используемой инфраструктуры. Требование Контейнеры не должны запускать прикладные процессы с привилегиями суперпользователя без необходимости. Использование непривилегированных пользователей снижает риск повышения привилегий и ограничивает последствия компрометации контейнера. Как это реализовано в Printum Основные контейнерные образы Printum используют непривилегированных пользователей для запуска сервисов. Базовые образы создают пользователя printum с идентификатором пользователя, отличным от root. В Dockerfile компонентов явно задаётся запуск процессов от непривилегированного пользователя: Мониторинг — пользователь printum; ПринтМенеджер — пользователь printum; File Server ПринтМенеджера — пользователь printum; Nginx ПринтМенеджера — пользователь nginx; PostgreSQL — пользователь postgres. Для доступа к подсистеме печати пользователь printum в контейнерах ПринтМенеджера дополнительно включается в группу lp. Базовые инфраструктурные образы Printum используют rootless-варианты образов, включая PostgreSQL, ClickHouse, Redis и Nginx. Контейнеры Printum не требуют запуска в privileged-режиме. Дополнительные Linux capabilities через cap_add не используются. Что требуется от инфраструктуры Использование rootless-режима контейнерного рантайма определяется используемой инфраструктурой и средствами контейнеризации заказчика. При необходимости эксплуатации в режиме Podman Rootless или аналогичных сценариях настройка контейнерного рантайма выполняется администраторами инфраструктуры заказчика. Ограничения и особенности В текущей версии отдельные служебные компоненты (CUPS и Mailcatcher) используют образы, для которых rootless-варианты ещё не реализованы. Для основных компонентов Printum запуск процессов от непривилегированных пользователей обеспечивается штатно. Отсутствие SUID-SGID файлов и утилит повышения привилегий Зона ответственности: Printum Коротко: Контейнерные образы Printum не содержат файлов с установленными битами SUID/SGID и не включают утилиты повышения привилегий, позволяющие получить дополнительные права внутри контейнера. Требование Контейнерные образы не должны содержать механизмы, позволяющие повысить привилегии процесса или пользователя внутри контейнера. Удаление SUID/SGID-файлов и утилит повышения привилегий снижает риск несанкционированного получения дополнительных полномочий при компрометации контейнера. Как это реализовано в Printum При сборке производственных контейнерных образов Printum выполняется удаление файлов с установленными битами SUID и SGID. Аналогичная обработка применяется для основных компонентов системы: Мониторинг; ПринтМенеджер; File Server ПринтМенеджера; CUPS. Дополнительно из образов удаляются утилиты повышения привилегий, включая su. Такой подход исключает использование механизмов повышения привилегий через SUID/SGID-бинарники и ограничивает возможности получения дополнительных прав внутри контейнера. Удаление выполняется на этапе сборки образов и входит в стандартный процесс подготовки production-версий контейнеров. Что обеспечивает Printum Printum обеспечивает: отсутствие файлов с установленными битами SUID и SGID в производственных образах; отсутствие утилит повышения привилегий; соответствие принципу минимально необходимых привилегий для контейнерных компонентов. Соответствие рекомендациям CIS Benchmark Зона ответственности: Printum + Заказчик / Интегратор Коротко: Printum реализует ряд рекомендаций CIS Benchmark для контейнерных сред, включая использование непривилегированных пользователей, удаление SUID/SGID-файлов, применение профилей безопасности SELinux и отказ от хранения секретов внутри контейнерных образов. Требование Контейнерная платформа должна соответствовать рекомендациям по безопасной настройке и эксплуатации контейнерных сред. Рекомендации CIS Benchmark направлены на снижение рисков компрометации контейнеров, ограничения привилегий процессов и обеспечение безопасного развёртывания приложений. Как это реализовано в Printum В составе контейнерной платформы Printum реализованы следующие меры безопасности: использование непривилегированных пользователей внутри контейнеров; отказ от запуска контейнеров в privileged-режиме; отсутствие дополнительных Linux capabilities через cap_add; удаление SUID/SGID-файлов и утилит повышения привилегий; применение профилей безопасности SELinux; отсутствие встроенных секретов, паролей и токенов в контейнерных образах; использование фиксированных версий контейнерных образов. Подробная информация приведена в соответствующих статьях раздела «Контейнеры». Что требуется от инфраструктуры Часть рекомендаций CIS Benchmark относится к настройке контейнерной платформы и инфраструктуры заказчика. К таким настройкам относятся: параметры контейнерного рантайма; ограничения CPU и памяти; использование read-only файловых систем контейнеров; аудит операционной системы; сканирование контейнерных образов; настройки оркестратора контейнеров. Настройка указанных механизмов выполняется администраторами инфраструктуры заказчика. Фиксированные теги контейнерных образов Зона ответственности: Printum + Заказчик / Интегратор Коротко: Printum использует контейнерные образы с фиксированными версиями компонентов. Теги latest для production-образов не используются. Требование Контейнерные образы должны использовать фиксированные версии компонентов, обеспечивающие воспроизводимость развёртывания и возможность контроля изменений между версиями. Использование фиксированных тегов позволяет исключить непредсказуемое изменение состава программного обеспечения при повторном развёртывании системы. Как это реализовано в Printum Production-образы Printum собираются на основе контейнерных образов с фиксированными версиями. Для основных компонентов используются версии, явно указанные в Dockerfile и конфигурации сборки. Контейнерные образы публикуются с версионными тегами, позволяющими однозначно определить используемую версию программного обеспечения. Фиксация версий обеспечивает воспроизводимость сборок и упрощает контроль изменений при обновлении системы. Что требуется от инфраструктуры Размещение контейнерных образов во внутреннем реестре организации, включая Nexus или иные корпоративные registry, определяется требованиями и политиками заказчика. Организация хранения, репликации и контроля доступа к реестру контейнерных образов выполняется средствами инфраструктуры заказчика. Хранение секретов в контейнерных образах Зона ответственности: Printum Коротко: Контейнерные образы Printum не содержат встроенных паролей, токенов, ключей API и других аутентификационных данных. Конфиденциальные параметры передаются в контейнеры во время запуска через переменные окружения. Требование Контейнерные образы не должны содержать аутентификационные данные, токены доступа, пароли и иные секреты в открытом виде. Секреты должны передаваться в приложение отдельно от образа контейнера и не входить в состав публикуемых артефактов. Как это реализовано в Printum Production-образы Мониторинга и ПринтМенеджера не содержат встроенных паролей, токенов, ключей API и иных аутентификационных данных. При сборке образов в них не копируются файлы конфигурации, содержащие секреты, включая файлы переменных окружения и ключи доступа. Конфиденциальные параметры передаются контейнерам во время запуска через переменные окружения, определяемые в файлах конфигурации развертывания. Для production-развертывания используются файлы .env, подключаемые средствами контейнерной платформы. В образах отсутствуют встроенные значения паролей баз данных, токенов интеграций и иных учётных данных. Контейнерные образы публикуются отдельно от конфигурации конкретного заказчика и могут использоваться в различных инсталляциях без хранения индивидуальных секретов внутри образа. Что требуется от инфраструктуры Управление секретами, защита файлов конфигурации и контроль доступа к переменным окружения выполняются средствами инфраструктуры заказчика. Конкретный способ хранения и передачи секретов определяется правилами эксплуатации и требованиями информационной безопасности организации.