Безопасность контейнеров и Kubernetes — это не один флаг в манифесте, а цепочка контролей: от того, какой образ попадает в кластер, до того, что нагрузке разрешено делать в рантайме и в сети. Контейнеры разделяют ядро хоста, поэтому слабая изоляция одного пода ставит под угрозу соседей и сам узел.
Соседние главы закрывают смежные темы: риски уровня приложения — в «OWASP Top 10 в системном дизайне», провенанс и подпись артефактов — в «Supply Chain Security», а устройство Kubernetes — в «Основах Kubernetes». Здесь фокус узкий: безопасность самих контейнеров и кластера — образы, контроль допуска, рантайм-изоляция, сеть и обнаружение.
Полезная рамка — 4C: Cloud → Cluster → Container → Code. Каждый внешний слой задаёт границу доверия для внутреннего, и пробитый внешний слой обесценивает защиту внутренних. По этим слоям мы и идём сверху вниз.
Практическая польза главы
Практика проектирования
Используйте материал по Безопасность контейнеров и кластера: образы, контроль допуска, рантайм-изоляция, сеть и обнаружение по слоям 4C, чтобы формировать архитектурные security-требования до этапа реализации.
Качество решений
Проверяйте решения через модель угроз, security invariants и управляемость контролей в production, а не только через чеклист соответствия.
Аргументация на интервью
Стройте ответ в формате threat -> control -> residual risk, показывая связь между бизнес-сценарием и техническими мерами защиты.
Формулировка компромиссов
Явно описывайте компромиссы по Безопасность контейнеров и кластера: образы, контроль допуска, рантайм-изоляция, сеть и обнаружение по слоям 4C: UX friction, накладная задержка (latency overhead), стоимость сопровождения и требования compliance.
Контекст
Основы Kubernetes
Эта глава про безопасность кластера, а как он устроен — в основах Kubernetes.
Безопасность контейнеров и ломается не на одном флаге в манифесте. Она держится цепочкой контролей: от того, какой вообще попадает в кластер, до того, что разрешено делать в рантайме и в сети. Цена слабого звена высокая: контейнеры делят ядро хоста, и дырявая изоляция одного пода ставит под удар соседей и сам узел.
Соседние главы закрывают смежные темы: разбираются в «OWASP Top 10 в системном дизайне», а провенанс и подпись артефактов — в «Supply Chain Security». Как именно работает (поды, плоскость управления, планировщик) — в «Основах Kubernetes». Здесь же фокус узкий: безопасность самих контейнеров и кластера — образы, контроль допуска, рантайм-изоляция, сеть и обнаружение.
Рамка, по которой удобно раскладывать решения, — 4C: Cloud → Cluster → Container → Code. Каждый внешний слой задаёт границу доверия для внутреннего, и пробить внешний слой — значит обесценить защиту всех вложенных. Дальше идём по этим слоям сверху вниз.
Модель угроз: что именно атакуют
Общее ядро хоста
Контейнеры — это процессы с и , делящие одно ядро хоста. Уязвимость ядра или неверная конфигурация даёт побег из контейнера и доступ к соседним нагрузкам.
Контроль: Минимум привилегий процесса, seccomp/AppArmor, отказ от privileged, при высоком риске — (gVisor/Kata).
Эскалация из контейнера
Контейнер от root, лишние Linux-, проброс хостовых путей или сокета демона позволяют вплоть до узла.
Контроль: non-root, read-only корневая ФС, сброс всех и запрет монтирования хостовых ресурсов.
Скомпрометированный образ
с уязвимостью, бэкдором или подменённой зависимостью попадает в кластер из недоверенного .
Контроль: Сканирование, минимальные базы, доверенные реестры — и проверка на контроле допуска, чтобы недоверенный образ не доехал до запуска.
Открытый API-сервер
Доступный из интернета API-сервер, со слабым или анонимный доступ открывают полный контроль над кластером.
Контроль: Закрытый , строгая аутентификация, минимальный RBAC и аудит-лог API.
Четыре слоя 4C
Cloud
Инфраструктура и провайдер: сеть, IAM, доступ к узлам и к самой плоскости управления. Если скомпрометирован этот слой, защита выше уже не помогает.
Cluster
Компоненты Kubernetes: API-сервер, etcd, , и .
Container
Образы, рантайм-профиль пода, , seccomp/AppArmor и изоляция от хоста.
Code
Приложение внутри контейнера: уязвимости зависимостей, секреты, валидация ввода — здесь применима уровня кода.
Внешний слой — граница доверия для внутреннего: компрометация Cloud обесценивает защиту Code.
Образы: что доверяем кластеру
| Контроль | Зачем | Действие при провале |
|---|---|---|
| Сканирование уязвимостей | Поиск известных CVE в слоях образа и зависимостях с по критичности и пути эксплуатации. | Блокировать публикацию и деплой образа с критичными уязвимостями. |
| Минимальные / distroless базы | Чем меньше пакетов, оболочек и инструментов в образе, тем уже поверхность атаки и меньше CVE для патчинга. | Запрещать «жирные» базовые образы для продакшн-нагрузок без обоснования. |
| Подпись и провенанс | Sigstore/cosign и по SLSA дают проверяемую цепочку «кто и из чего собрал образ». | Не допускать в кластер образы без валидной подписи и аттестации сборки. |
| Запрет тега latest | Плавающий тег latest ломает воспроизводимость: один и тот же манифест разворачивает разный код в разное время. | Требовать неизменяемые ссылки по digest (sha256) вместо плавающих тегов. |
Сборка и цепочка поставки
- Генерировать при сборке — состав образа фиксируется и позволяет за минуты найти затронутые нагрузки при новой уязвимости.
- Тянуть образы только из доверенных ; внешние образы зеркалировать и пересканировать, а не использовать напрямую.
- Прикладывать (, результаты скана) и подписывать её — это часть .
- Проверять подпись и провенанс на admission: образ без валидной подписи доверенного издателя в кластер не попадает.
Контроль допуска (admission control)
| Механизм | Роль | Пример |
|---|---|---|
| Validating webhook | Принимает или отклоняет объект, не меняя его — чистый контроль политики. | Отказать поду с privileged: true. |
| Mutating webhook | Дополняет или правит объект до сохранения в etcd. | Доставить -прокси mesh, проставить runAsNonRoot по умолчанию. |
| Pod Security Admission | Встроенный контроллер, применяющий Pod Security Standards на уровне в режимах enforce / audit / warn. | Профили privileged → baseline → restricted по нарастанию строгости. |
| OPA Gatekeeper / Kyverno | для произвольных правил, которых нет во встроенных стандартах. | Разрешённые реестры, обязательные метки, лимиты ресурсов, запрет hostPath. |
Pod Security Admission закрывает базовый минимум; Gatekeeper/Kyverno — произвольные политики организации.
Рантайм-изоляция пода
runAsNonRoot + runAsUser
Процесс не root внутри контейнера — компрометация не даёт прав суперпользователя.
readOnlyRootFilesystem
Корневая ФС только для чтения; запись — лишь в явные тома, что мешает закрепиться.
drop ALL capabilities
Снимаются все ; добавляются обратно только реально нужные (обычно — никакие).
seccomp: RuntimeDefault
Фильтр системных вызовов сужает доступную ядру поверхность атаки из контейнера.
allowPrivilegeEscalation: false
Запрещает рост привилегий процесса через setuid-бинарники и подобные механизмы.
privileged: false (всегда)
Привилегированный контейнер фактически равен root на узле — почти всегда это ошибка.
Усиленная изоляция для недоверенного
- Пользовательские пространства имён (User namespaces): root внутри контейнера маппится на непривилегированного пользователя на хосте — побег теряет смысл без эскалации.
- Песочницы (gVisor, Kata Containers): перехват системных вызовов или лёгкая микро-ВМ дают вторую границу для недоверенных и мультитенантных нагрузок ценой накладных расходов.
- Разделение узлов и по уровню доверия: не смешивать интернет-фронт и привилегированные системные нагрузки на одних узлах.
Сеть, доступ и секреты
- с : трафик между подами разрешается явно, а не открыт по умолчанию.
- по принципу : никаких
cluster-adminдля нагрузок, отдельные (ServiceAccount) на сервис. - Секреты не в переменных окружения и не в образе: внешний или , монтирование томом, шифрование etcd.
- между сервисами через : шифрование и взаимная аутентификация по умолчанию, в духе .
Обнаружение в рантайме
- Рантайм-детект (Falco и сенсоры на ): аномальные системные вызовы, запуск в контейнере, неожиданные сетевые соединения и запись в чувствительные пути.
- Аудит-лог API-сервера: кто, что и когда менял в кластере — основа разбора инцидентов и обнаружения злоупотреблений .
- Сверка фактического состояния пода с допущенной политикой: ловит ручные привилегированные правки в обход .
Компромиссы и частые ошибки
Запускать нагрузки как privileged или от root «чтобы заработало» — это эквивалент root на узле.
Держать всё в default без сетевых политик и Pod Security Admission: тогда любой под видит любой и нет границы, по которой можно разнести уровни доверия.
Доверять образам без сканирования, подписи и проверки провенанса на контроле допуска: первый же скомпрометированный образ доезжает до запуска незамеченным.
Класть секреты в переменные окружения и в образ — они утекают в логи, дампы процессов и слои образа.
Оставлять API-сервер доступным из интернета с широким или анонимным .
Не ограничивать исходящий трафик (): даёт скомпрометированному поду выкачивать данные и тянуть нагрузку.
Жёсткая изоляция стоит удобства и иногда производительности (песочницы) — это осознанный размен под уровень доверия нагрузки.
Источники и материалы
Карта источников: NSA/CISA даёт чеклист усиления защиты (hardening); документация платформы Kubernetes — текущую модель мер безопасности (security controls), Pod Security Standards и Pod Security Admission. Версионные детали меняются, поэтому перед внедрением сверяйте свою версию платформы Kubernetes, включённые контроллеры допуска (admission controllers), профили runtimeClass/seccomp и возможности движка политик — иначе чеклист разойдётся с тем, что реально применяется в кластере.
Связанные главы
- Основы Kubernetes - объясняет, как устроены поды, плоскость управления и планировщик — модель, на которую опираются все меры безопасности этой главы.
- OWASP Top 10 в системном дизайне - даёт архитектурную рамку рисков уровня приложения (слой Code модели 4C), который живёт внутри контейнера.
- Supply Chain Security - углубляет провенанс, (SBOM) и подпись артефактов, на которые опираются проверки образов на admission.
- Secrets Management Patterns - раскрывает хранение и ротацию секретов, которые нельзя класть в образ и переменные окружения пода.