Ты разместил 1С, терминальные сервисы и внутренние приложения в одном Kubernetes-кластере. Серверы загружены плотнее, свободных ядер почти нет. Завтра один чужой образ сможет выполнить команду на хосте, подменить кэш соседнего пода или остановить containerd из-за утечки памяти: такие сценарии описаны в CVE-2026-53488, CVE-2026-50195 и CVE-2026-47262.
После этих уязвимостей сервер нельзя выбирать только по ядрам, памяти и IOPS. В расчёт входит радиус поражения: сколько бизнес-сервисов остановятся, если придётся изолировать один узел.
Твоя задача — собрать платформу, где подозрительную нагрузку можно отключить без остановки 1С, файлового хранилища и резервного копирования. Где-то хватит отдельных пулов узлов. Где-то потребуется отдельный физический сервер. Граница проходит не между namespace, а между допустимыми последствиями аварии.
Сканер проверяет образ, но не видит будущую загрузку
Статический сканер разбирает слои образа, сверяет пакеты с базой CVE и проверяет лицензии. Он не анализирует код, который ENTRYPOINT скачает после запуска. Например, стартовый скрипт может выполнить curl | bash и получить payload с внешнего сервера — в проверенных слоях этого файла не будет.
После запуска такой контейнер ищет не только переменные окружения. Целями становятся приватные SSH-ключи в ~/.ssh/, учётные данные AWS в ~/.aws/credentials, файлы GCP в ~/.config/gcloud/ и конфигурация Azure CLI в ~/.azure/.
В Kubernetes рядом лежит ещё одна цель — токен service account по пути /var/run/secrets/kubernetes.io/serviceaccount/token. Права токена зависят от настроек кластера, но сам переход уже опасен: атака перестаёт быть проблемой одного контейнера и получает доступ к ресурсам Kubernetes.
Инцидент с Trivy показал, как далеко уходит такая цепочка. Атакующие использовали скомпрометированный токен с правами на две GitHub-организации, затронули два GitHub Action и через украденные данные добрались до десятков npm-пакетов.
Поэтому отметка «скан пройден» не разрешает ставить образ рядом с бизнес-нагрузкой. Она подтверждает лишь то, что сканер не нашёл известную проблему в доступных ему слоях.
Общий containerd связывает соседние сервисы
В containerd 1.7–2.3 обнаружили пять уязвимостей CRI-плагина. Для закупки и размещения особенно важны три.
CVE-2026-50195 с оценкой CVSS 8,8 позволяет отравить кэш образов на общем Kubernetes-узле и добиться выполнения кода между подами. CVE-2026-53488 с CVSS 8,3 использует необработанную инструкцию LABEL специально собранного образа для передачи произвольной команды хосту. CVE-2026-47262 с CVSS 6,5 вызывает неконтролируемое потребление памяти и может завершить процесс containerd.
Здесь namespace не даёт нужной границы. Поды остаются на одном физическом узле, пользуются общим runtime и зависят от его работоспособности.
Из этого следует прямое правило размещения: публичные, подрядные и экспериментальные образы не должны работать на физических узлах с 1С, контроллерами домена, управляющими компонентами кластера и хранилищем резервных копий. Для них нужен отдельный пул. Если кластер мал и отдельный пул получается только на бумаге, ставь отдельный сервер.
Такое разделение требует резерва. Если карантинный пул состоит из одного узла без свободной ёмкости в другом контуре, его отключение превратится в остановку сервиса. Покупать нужно не среднюю загрузку, а способность пережить изоляцию машины.
Выход через runc заканчивается доступом к узлу
В ноябре 2025 года раскрыли три уязвимости runc с оценкой CVSS 7,3: CVE-2025-31133, CVE-2025-52565 и CVE-2025-52881. Они используют ошибки mount-механизмов и обход проверок Linux Security Modules. runc работает как низкоуровневый runtime в Docker, Podman и Kubernetes.
При успешной атаке из Kubernetes злоумышленник может добраться до kubelet узла. После этого расчёт «потеряем один контейнер» уже не годится. Считать надо весь хост и все размещённые на нём сервисы.
Управляющий контур кластера и бизнес-приложения не должны зависеть от одной физической машины. В рабочем контуре нужен хотя бы один узел, который примет критичную нагрузку после отключения заражённого хоста. Это не обязательно означает полный запас под каждую виртуальную машину: сначала перенеси сервисы с коротким допустимым простоем, а гарантированную ёмкость оставь для 1С, аутентификации и систем управления.
Единственная копия данных на локальных дисках такого узла тоже не считается резервом. Если хост пришлось изолировать или переустановить, данные пропали вместе с вычислительной мощностью. Перед закупкой проверь не только объём массива, но и как проверить бэкап до аварии.
Лимит памяти остановит payload, но не закроет вход
В январе 2026 года криптомайнер XMRig 6.24.0 попал в производственный Kubernetes-кластер и занял 2 ГБ памяти за 30 секунд. Контейнер достиг лимита, получил OOMKilled и завершился.
Лимит сократил время работы майнера. Уязвимость при этом осталась: атакующий использовал RCE без аутентификации в Next.js 15.3.4 с оценкой CVSS 10,0. Исправление уже существовало в версии 15.3.6 и новее.
Ресурсные ограничения и резерв мощности решают разные задачи. Лимит не позволяет одному контейнеру съесть всю память узла. Резерв оставляет место соседним сервисам, пока контейнер перезапускается, специалисты сохраняют данные для расследования, а нагрузка переезжает на чистый хост.
Значит, память нельзя считать только как сумму обычного потребления приложений. В спецификацию входят лимиты контейнеров и аварийный запас. Если после исчерпания лимита одним подом узел уходит в swap или начинает убивать соседние процессы, запас существует лишь в таблице поставщика.
Точный объём зависит от профиля нагрузки. Но критерий проверяется без гадания: при падении одного узла оставшиеся машины должны принять критичные поды и сохранить запас памяти для runtime, kubelet и системных компонентов.
Даже образ сканера требует проверки происхождения
Доверенное название репозитория не доказывает, что образ выпустил разработчик проекта. В марте 2026 года в Docker Hub появились вредоносные версии Trivy 0.69.4–0.69.6. Теги 0.69.5 и 0.69.6 загрузили без соответствующих релизов на GitHub; последней известной чистой версией осталась 0.69.3.
Этот случай ломает удобную схему «сначала проверяем образ сканером, потом запускаем». Сам сканер тоже приходит как артефакт цепочки поставок и требует проверки.
В закупочной спецификации поэтому нужны измеримые компоненты, а не строка «средства защиты контейнеров»:
- отдельный registry, недоступный для произвольной загрузки образов;
- хранение и запуск образов по digest, а не по плавающему тегу;
- карантинный пул узлов для первого запуска;
- централизованные логи вне проверяемого узла;
- независимое хранилище резервных копий;
- свободная ёмкость для изоляции и обновления одного узла.
Registry и логи потребуют дисков, памяти и резервного копирования. Карантинный пул — ещё одного сервера или выделенной группы машин. Это цена ограничения радиуса поражения, а не необязательная надстройка к кластеру.
Что заложить в закупку
Правило для директора звучит так: если один контейнер способен остановить несколько бизнес-сервисов, экономия на отдельном узле уже создала общую точку отказа.
Минимальная схема включает отдельный пул для недоверенных нагрузок, резервный узел для эвакуации, независимое хранилище бэкапов и ресурсы под централизованные логи. Перед согласованием спецификации проверь пять вещей:
- Какие сервисы делят физический хост и общий runtime?
- Останется ли кластер работоспособным после изоляции одного узла?
- Где лежат registry, журналы и резервные копии?
- Хватит ли памяти соседним сервисам, если один контейнер исчерпает лимит?
- Можно ли обновить containerd и runc без остановки всех бизнес-приложений?
Для самостоятельных установок AWS рекомендует перейти на исправленные версии containerd. До обновления AWS советует разрешать загрузку только доверенных образов, а также ограничить импорт образов и запуск подов доверенными пользователями.
Если поставщик не может показать эту схему на уровне физических узлов, дисков и доступной памяти, он посчитал серверы под штатный день. Тебе нужна конфигурация, которая выдержит день изоляции.
