Безопасность Docker и Kubernetes (K8s): практика защиты контейнеров в 2026 году

15.04.2026

Алексей Мишаев

Автор

Контейнеризация стала стандартом де-факто для разработки, доставки и эксплуатации приложений. Docker и Kubernetes составляют базовую инфраструктуру ИТ-продуктов в компаниях любого размера — от стартапов до крупных корпораций. Однако вместе с удобством и скоростью развертывания контейнеры принесли и новые, часто недооцененные, риски безопасности.

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

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

Содержание

Самые распространенные сценарии атак на контейнеры

По данным отчетов об уязвимостях за последние два года, темпы миграции критически важных приложений в Kubernetes и бесшовные конвейеры CI/CD значительно опережают темпы созревания компетенций по их защите. В погоне за скоростью развертывания и масштабируемостью команды нередко воспринимают безопасность контейнеров как часть ответственности облачного провайдера, забывая, что модель общей ответственности (shared responsibility) в контейнерной экосистеме работает иначе.

Злоумышленники, в свою очередь, давно сместили фокус с классических периметров защиты на стадию разработки и оркестрации, из-за чего уязвимости конфигурации и цепочки поставок становятся главным вектором проникновения в корпоративные сети. Именно с ошибками конфигурации и доступа связана основная часть инцидентов в среде оркестрации — это те случаи, где разработчик оставляет микросервису слишком много прав, а сетевые политики остаются в состоянии «разрешено все».

Самые распространенные сценарии атак на контейнеры формируют фактическую карту разведки (TTPs) для современных пентестеров и APT-групп. Реальность такова, что многие из этих сценариев реализуются максимально просто.

Вредоносные образы в публичных реестрах. Docker Hub и другие реестры содержат миллионы образов, многие из которых никто не проверяет. Загрузка образа с вшитым майнером, бэкдором или эксплойтом — не реальные кейсы, которые фиксируются ежедневно.
Атаки на цепочки поставок. Компрометация одного популярного образа или базового слоя уже приводили к поражению тысяч приложений по всему миру. Инциденты с атаками на зависимости и образы стали системной проблемой.
Некорректные сетевые политики. В K8s по умолчанию все поды могут общаться со всеми. Это означает, что даже один скомпрометированный контейнер открывает злоумышленнику доступ ко всей кластерной сети.
Секреты в ENV-переменных. Пароли, токены, ключи API, прописанные в переменных окружения или прямо в Dockerfile, попадают в логи, в образы, в системы мониторинга — и в результате становятся легкой добычей.
Запуск контейнеров от root. Если контейнер работает с привилегиями суперпользователя, выход за его пределы дает злоумышленнику контроль над хостом.

Все это не теоретические риски. Уязвимости в конфигурации контейнеров регулярно попадают в отчеты об инцидентах, а пентестеры и злоумышленники научились автоматизировать поиск таких ошибок. Теперь пройдемся по методам работы с этими угрозами.

Безопасность образов: сканирование на уязвимости и работа с доверенными реестрами

Образ контейнера — это первая и самая главная точка контроля. Если образ скомпрометирован на этапе сборки, никакие средства runtime-защиты не спасут. Злоумышленник либо внедрит вредоносное ПО в слои образа, либо использует известные уязвимости в компонентах, из которых этот образ собран.

Большинство Docker-образов собираются на базе публичных родительских образов. Эти образы содержат операционную систему и набор пакетов, в которых регулярно находят критические уязвимости. Проблема усугубляется тем, что разработчики часто:

используют теги latest, не фиксируя конкретную версию;
месяцами не обновляют базовые образы;
добавляют в финальный образ инструменты отладки и компиляторы, которые не нужны в продакшене, но увеличивают поверхность атаки.

В итоге сценарий атаки может выглядеть так: злоумышленник сканирует Docker Hub на предмет образов с известными уязвимостями (например, Log4Shell в образах Java-приложений) и автоматически находит компании, использующие их в продакшене. Дальше — эксплуатация и проникновение.

Поэтому сканирование образов на уязвимости должно стать обязательной стадией CI/CD-пайплайна. Лучший способ — не надеяться на «ручные проверки», а автоматизировать процесс.

Владислав Шелепов

Аналитик угроз GSOC компании «Газинформсервис»

Чтобы в продуктивную среду попадали только проверенные образы, нужно выстроить многоступенчатый контроль внутри конвейера сборки и развертывания приложений. Такой подход сегодня называют смещением безопасности влево (Shift Left), то есть переносом проверок на самые ранние этапы жизненного цикла разработки. Первый уровень защиты — статический анализ конфигураций. Еще до того, как образ будет собран, необходимо проверить Dockerfile на наличие типовых ошибок безопасности. Здесь могут помочь такие инструменты, как Hadolint. После сборки образа в конвейере нужно проводить сканирование на известные уязвимости, осуществлять проверку Policy-as-Code (“Политики как код”) и внедрить верификацию образов.

Станислав Агибалов

Эксперт отдела безопасной разработки Angara Security

Основным инструментом [для нас] является Kaspersky Security для контейнеров, интегрируемый в конвейер непрерывной интеграции и непрерывного развёртывания (CI/CD пайплайн). Он выполняет сканирование образов на уязвимости, вредоносное ПО, ошибки конфигурации и наличие секретов. Политики безопасности позволяют автоматически останавливать конвейер разработки (пайплайн) при нарушениях. Дополнительно обеспечивается проверка подписей через Admission Controller, блокирующая неподписанные образы, и используется режим SBOM (Software Bill of Materials — перечень библиотек, конкретных файлов и зависимостей, имеющих отношение к разрабатываемому ПО) для оптимизации ресурсов.

Trivy — пожалуй, самый популярный инструмент с открытым исходным кодом. Его преимущества — это простота установки из одного бинарного файла, возможность сканировать не только ОС-пакеты, но и зависимости языков программирования (npm, pip, gem, composer и др.), а также IaC-файлы (Dockerfile, Terraform, Kubernetes). Инструмент легко встраивается в GitLab CI, GitHub Actions, Jenkins.

Clair — более старый инструмент от CoreOS (Red Hat), который используется в системах реестров (например, в Quay). Он требует отдельной базы данных и сложнее в эксплуатации, но хорошо интегрируется с крупными экосистемами.

Александр Голуба

Ведущий архитектор отдела комплексной инфраструктуры Cloud Networks

Суть в том, что CI/CD пайплайн может быть гибко настроен, поэтому сложно перечислить все процессы, ведь их перечень зависит от инфраструктуры. К обязательному набору относится сканирование контейнерных образов и зависимостей (например, с помощью Trivy), проверка Dockerfile и Kubernetes-манифестов, цифровые подписи образов (Cosign). Сканирование, как правило, выполняется при каждом билде, а образы рекомендуется пересобирать и повторно проверять не реже одного раза в неделю и при появлении новых CVE.

Как использовать эти инструменты:

Добавьте в пайплайн сборки этап сканирования образа Trivy в режиме --severity CRITICAL,HIGH. При обнаружении уязвимостей высокой или критической степени сборка должна падать.
Настройте сканирование уже загруженных в реестр образов по расписанию. Уязвимости появляются в уже «стабильных» образах, когда в базовых ОС-пакетах находят новые CVE.
Используйте отдельную утилиту trivy image --ignore-unfixed, если нужно различать исправленные и неисправленные уязвимости — это помогает отделить реальные риски от «фонового шума».

Второй компонент безопасности связан с использованием доверенных реестров. Docker Hub, GitHub Container Registry и другие публичные реестры удобны, но создают риски подмены образов, трудности с контролем их удаления, настройками политик безопасности.

Поэтому для защищенной инфраструктуры корпоративный реестр (Harbor, Nexus, GitLab Container Registry, Artifactory) — это базовая необходимость. Он обеспечивает контроль доступа (кто может загружать и выгружать образы), поддержку встроенных сканеров уязвимостей вроде упомянутых Trivy и Clair, подписи образов для гарантии того, что образ был создан в доверенном пайплайне. Разработчики смогут подписывать образы приватным ключом на этапе сборки, а в кластере настроить валидацию подписи. Это исключает возможность подмены образа в реестре или между реестром и кластером. Кроме того, приватный реестр позволяет управлять жизненным циклом контейнеров, автоматически удаляя старые, неиспользуемые образы.

Дмитрий Калинин

Руководитель департамента по работе с уязвимостями и инцидентами ИБ «Бастион»

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

Роман Корчагин

DevSecOps-инженер «Лаборатория Числитель»

В контейнерной платформе «Штурвал» мы используем подход, состоящий из трех ключевых этапов: анализ состава ПО (SCA), подпись образов с помощью Cosign и контроль развертывания через Admission Controller. На первом этапе проводится анализ зависимостей и компонентов образа. Для выявления известных уязвимостей мы используем Trivy. Но в процессах безопасной разработки можно применять и другие инструменты с открытым исходным кодом — например, Syft, DependencyTrack и DependencyCheck. После устранения или принятия обнаруженных уязвимостей образ подписывается с помощью Cosign. Далее Admission Controller (в нашем случае Kyverno, хотя, может использоваться и Gatekeeper) проверяет подпись и не допускает развертывания неподписанных или недоверенных артефактов в кластере. Такой подход помогает защититься от целого класса атак на цепочку поставок (supply chain).

Следующий шаг — защита уже запущенных контейнеров (runtime).

Runtime защита: запуск не от root и ограничение ресурсов

Даже если образ безопасен и подписан, runtime-среда остается ключевой зоной риска. Контейнеры разделяют ядро хоста, и ошибки в конфигурации или уязвимости в механизмах изоляции могут привести к компрометации всей инфраструктуры. Две важнейшие практики защиты на этапе работы контейнера — запуск от непривилегированного пользователя и жесткое ограничение ресурсов.

По умолчанию контейнеры запускаются внутри контейнера от пользователя root. Хотя он изолирован от хоста (если не использовать --privileged), эксплуатация уязвимостей выхода за пределы контейнера позволяет атакующему получить root-доступ к хосту.

Дмитрий Евдокимов

Технический директор Luntry (входит в ГК «Солар»)

Анализ образов — это непрерывный процесс, поэтому контроля только в CI\CD Pipeline совсем недостаточно, необходимо это делать и в Image registry, и в Runtime. Частота пересборки также зависит от необходимости что-то обновлять и изменять. Для процесса на базе open source решений понадобится 5-6 утилит, над которыми нужно будет потом еще написать и поддерживать обвязку, чтобы они были слаженным «оркестром», а также внести ряд изменений, чтобы они начали понимать специфику российских ОС, БДУ ФСТЭК.

Поэтому разработчики должны убедиться, что контейнеры запускаются только от непривилегированного пользователя. В Dockerfile это инструкция USER 1000:1000 (создайте пользователя с UID не root). В Kubernetes — securityContext.runAsNonRoot: true.

В продуктивной среде никогда нельзя использовать --privileged. Этот флаг отключает практически все механизмы изоляции и дает контейнеру доступ к устройствам хоста, позволяя легко выполнить escape. Кроме того, нужно удалять лишние capabilities: вместо --cap-drop=ALL с последующим добавлением только необходимых (--cap-add=NET_BIND_SERVICE для приложений, «слушающих» порты ниже 1024).

Начиная с версии 20.10, Docker поддерживает запуск демона без прав root. Это снижает риск даже в случае компрометации самого демона. При этому нужно понимать, что запуск от non-root — это не панацея. Если контейнеру нужен доступ к определенным ресурсам хоста (например, к Docker-сокету), даже непривилегированный пользователь внутри контейнера может использоваться как прокси для атаки. Поэтому ключевое правило — запрещать контейнерам доступ к любым ресурсам, которые им не нужны для выполнения бизнес-функции.

Владислав Шелепов

Аналитик угроз GSOC компании «Газинформсервис»

Основной инструмент с открытым исходным кодом для [мониторинга и предотвращения аномалий в рантайме] — Falco. Он перехватывает системные вызовы на узле и сравнивает их с набором правил. Если в контейнере, который должен просто отвечать на HTTP-запросы, вдруг запускается командная оболочка, или если процесс пытается читать файлы в защищенных директориях, Falco генерирует события, которые могут перерасти в инциденты. Существуют также и коммерческие продукты. Они могут предлагать не только обнаружение угроз, но и возможности реагирования, интеграцию с системами сбора и корреляции событий, а также более тонкую настройку правил.

Федор Масленников

Заместитель технического директора платформы «Боцман» (входит в «Группу Астра»)

Для решения такого рода задач лучше воспользоваться специализированными решениями, которые могут быть развернуты в среде Kubernetes и предоставлять подробную информацию о происходящих процессах в контейнерах с возможностью отправки отчетов и алертов. Наиболее популярны в этой области такие инструменты, как KasperskyContainer Security, Luntry, PT Container Security, NeuVector. Самое главное – вовремя обновлять базы таких приложений, чтобы иметь возможность обнаружения самых новых уязвимостей и угроз.

Важно учитывать и подводные камни:

Многие официальные образы по умолчанию запускаются от root. Поэтому необходимо проверять Dockerfile и переопределять USER.
Некоторые приложения требуют root для старта (например, если им нужно открыть порт ниже 1024). Решение — использовать capabilities (NET_BIND_SERVICE) вместо полноценного root.
В Kubernetes runAsNonRoot: true вызовет ошибку запуска, если образ явно не определяет пользователя. Это полезно — так можно явно фиксировать, что root-контейнеры не допускаются.

Переходим к теме ограничения ресурсов. Контейнеры, запущенные без ограничений, могут монополизировать ресурсы хоста. В результате возникает угроза DoS внутри кластера, когда скомпрометированный контейнер или просто «прожорливое» приложение (memory leak) потребляет всю оперативную память. Другой сценарий — «шумный сосед»: один контейнер потребляет все процессорное время, остальные работают медленно или уходят в таймаут. Этой механикой также пользуются криптомайнеры. Злоумышленники могут скрытно использовать мощности хоста для генерации криптовалюты.

Чтобы избежать этих проблем, следует всегда задавать лимиты CPU и оперативной памяти в конфигурации запуска контейнера/пода. При этом важно не забывать и про ограничение запросов.

Устанавливать лимиты нужно осознанно: слишком жесткие ограничения могут привести к OOMKill при легитимных пиках нагрузки. Если приложение регулярно упирается в лимиты, это сигнал либо к настройке автоскейлинга, либо к оптимизации самого приложения.

Дмитрий Евдокимов

Технический директор Luntry (входит в ГК «Солар»)

Самым правильным и действенным подходом при рантайм защите в Kubernetes является гибридный подход. Он позволяет сочетать blacklist- и whitelist-подходы. При blacklist-подходе мы четко задаем «что такое плохо» и получаем четкие сработки под наш запрос, но описать все практически невозможно. При whitelist-подходе мы обучаемся на легитимном поведении микросервиса и фиксируем аномалии, которые могут ловить даже неизвестные атаки, но это требует дополнительной подготовительной фазы. Сочетая два эти метода, мы получаем уникальную возможность без большого количества «шума» ловить даже неизвестные атаки. Ни один из бесплатных инструментов не дает возможность гибридного подхода, да и подход через whitelist придется дописывать самостоятельно в любом случае. Такие продвинутые возможности есть только у коммерческих решений.

Следующий шаг к безопасности контейнеров в Kubernetes — сетевая сегментация.

Сетевая сегментация K8s: почему нельзя строить плоскую сеть

В традиционных виртуальных средах сегментация сетей — это базовое правило. В Kubernetes по умолчанию действует обратный принцип: все поды могут общаться со всеми. Это удобно для разработки, потому что микросервисам часто нужно взаимодействовать друг с другом. Но в продуктиве возникает критическая уязвимость: компрометация одного контейнера открывает доступ ко всей кластерной инфраструктуре.

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

Решением для этой проблемы становятся грамотно настроенные сетевые политики. Ключевой механизм сегментации в Kubernetes — Network Policies, которые определяют, какие поды могут обмениваться трафиком. Важно понимать: они не работают «из коробки»; поддержка зависит от используемого сетевого плагина (CNI). Современные плагины (Calico, Cilium, Weave Net), реализуют эту функциональность, но есть и такие, где ее нет.

Станислав Агибалов

Эксперт отдела безопасной разработки Angara Security

Для базовой микросегментации достаточно встроенных Network Policies. При необходимости контроля на уровне приложений и шифрования рекомендуется Cilium. Дополнительно можно использовать Kaspersky Security для контейнеров — управление сетевыми соединениями в нём осуществляется через графический интерфейс с возможностью задания разрешённых IP-адресов (CIDR), портов TCP/UDP и URL, что упрощает создание политик, однако он не заменяет продвинутые сетевые функции уровня L7.

Владислав Шелепов

Аналитик угроз GSOC компании «Газинформсервис»

Прежде чем внедрять политики, нужно понять, какой трафик вообще существует в кластере. Рекомендуется сначала установить инструменты для наблюдения, например Cilium Hubble. Они покажут, какие сервисы с какими взаимодействуют, на каких портах и по каким протоколам. После этого можно проектировать политики, отталкиваясь от реальной картины.

Первое, что нужно сделать — это изменить подход от «разрешено все» к «запрещено все, что не разрешено». Идеальная политика по умолчанию блокирует весь входящий и исходящий трафик для всех подов в пространстве имен. После этого администраторы точечно открывают только необходимые соединения.

Основные принципы построения политик:

Селекторы. Политики используют метки (labels), чтобы выбирать, к каким подам применять правила и какие поды могут обмениваться трафиком.
Входящий и исходящий трафик. Можно ограничивать, откуда под может принимать соединения (ingress) и куда он может отправлять запросы (egress).
Межпространственные связи. Если нужно разрешить трафик между разными пространствами имен (namespace), правила могут ссылаться на них.
Системные сервисы. Нельзя забывать о критически важных компонентах кластера — DNS, метриках, API-сервере. Политики должны предусматривать для них исключения, иначе можно нарушить работу всего кластера.

Внезапное включение политик в работающем кластере может сломать приложения. Следует начинать с непродуктивных сред, затем внедрять правила в режиме наблюдения (если плагин поддерживает логирование блокировок), и только потом переходить к блокировке.

Когда политика блокирует трафик, Kubernetes по умолчанию не генерирует событий. Чтобы узнать, что соединение заблокировано, понадобится мониторинг сетевого плагина (например, Hubble для Cilium) или контроль косвенных признаков (самый простой — приложение не работает).

Необходимо учитывать влияние на производительность. Чем больше политик, тем выше нагрузка на сетевой плагин. В больших кластерах с тысячами правил нужно выбирать CNI, который умеет эффективно масштабироваться (Calico, Cilium), и избегать избыточных или пересекающихся политик.

Также важно помнить про исходящий трафик. Разработчики часто ограничивают только входящие соединения, позволяя самим подам отправлять запросы куда угодно. Это позволяет скомпрометированному поду передавать данные наружу или сканировать внешние ресурсы. Политики должны контролировать и исходящие соединения, разрешая только необходимые (например, доступ к DNS, к конкретным внешним API, к базе данных).

Роман Корчагин

DevSecOps-инженер «Лаборатория Числитель»

Для реализации подобной модели обычно используются CNI-плагины, например Cilium или Istio. Они позволяют не только управлять сетевыми политиками, но и делать микросегментацию и шифровать трафик внутри кластера с помощью mTLS. Кроме того, многие элементы этой архитектуры можно автоматизировать. Например, с помощью Kyverno при создании нового пространства имен можно автоматически применять базовую сетевую политику Cilium, которая запрещает весь входящий и исходящий трафик, за исключением обращений к kube-DNS.

Наконец, нужно учитывать, что в пространстве kube-system работают компоненты, обеспечивающие работу кластера. Неосторожные политики могут привести к полной недоступности кластера. Поэтому внедрение сегментации должно стартовать с пространств имен приложений, оставляя системные компоненты под наблюдением.

Следующий раздел — управление секретами, грамотные практики работы с переменными, Kubernetes Secrets и внешними хранилищами.

Управление секретами: почему нельзя хранить пароли в ENV-переменных

API-ключи, пароли от баз данных, токены доступа к облачным сервисам — все это необходимо приложениям для работы, но при неосторожном обращении становится идеальной целью для атакующих.

Самый распространенный, но и самый опасный подход — передавать секреты через переменные окружения. Выглядит это просто: в Dockerfile или docker-compose прописываются `ENV DB_PASSWORD=secret`, или в манифесте Kubernetes добавляются переменные в секцию `env`. Так приложение всегда знает, где искать данные, но у продукта возникают серьезные проблемы безопасности. В больших системах количество переменных окружения переваливает за десятки. Они дублируются между сервисами, теряются, меняются несогласованно — управление превращается в хаос.

Многие приложения и системы логирования записывают переменные окружения при старте. В итоге пароль оказывается в логах контейнера, в системах сбора логов, в агрегаторах вроде ELK, а к ним доступ может быть шире, чем к самим секретам. Команды вроде docker inspect или kubectl describe pod показывают переменные окружения в открытом виде. Любой, у кого есть доступ к API кластера или к хосту, может прочитать секреты. Переменные окружения также передаются всем дочерним процессам. Если приложение запускает внешнюю утилиту, та получит все секреты в свое окружение, может их залогировать или передать.

В Kubernetes для хранения секретов есть специальный объект — Secret. Он позволяет отделить конфиденциальную информацию от описания приложения. В результате секреты можно монтировать как файлы в контейнер или передавать как переменные окружения (хотя последнее не решает проблему утечки через логи).

Данные Secret хранятся в распределенном хранилище кластера. В контейнере появляется файл, например, /secrets/db-password, с нужным содержимым. Как следствие, приложение читает пароль из файла, а не из переменной окружения.

В этом случае секреты не попадают в логи и не видны в docker inspect. Доступ к ним можно контролировать через ролевую модель, чтобы только определенные сервис-аккаунты могли читать конкретные секреты. При смене секрета можно обновить его в кластере — смонтировавшие его приложения увидят новое значение без перезапуска, если настроен механизм синхронизации.

Федор Масленников

Заместитель технического директора платформы «Боцман» (входит в «Группу Астра»)

В первую очередь стоит отказаться от использования встроенного функционала Kubernetes по созданию и управлению объектами типа Secret, поскольку обеспечить их безопасность порой довольно сложно. Надежнее использовать специализированные инструменты и интегрировать их в процессы CI/CD, например Hashicorp Vault с Vault Secrets Webhook. Загрузка секретов напрямую в память приложения является хорошим способом защиты секретов от утечек.

Дмитрий Евдокимов

Технический директор Luntry (входит в ГК «Солар»)

Права на list или watch к секретам равносильны доступу к их содержимому, поэтому не стоит давать даже минимальных прав, если этого не требуется. Стоит использовать специализированные внешние хранилища секретов. В процессах разработки не стоит хранить «секреты» в переменных, важно ограничивать доступ к ним внутри «пода». Если в поде несколько контейнеров, то распределять переменные нужно в определённые контейнеры, оставляя только нужные. Если говорить о манифестах Kubernetes, то к ним нужно относиться, как к обычному исходному коду, и манифесты с секретами не должны попадать в репозиторий исходного кода.

Для крупных инфраструктур Kubernetes Secrets — это только первый шаг. Более зрелый подход — использовать внешние системы управления секретами. Отраслевой стандарт — HashiCorp Vault. Он хранит секреты в зашифрованном виде, предоставляет аудит доступа, умеет автоматически генерировать и ротировать секреты, может выдавать временные учетные записи в базах данных вместо статичных паролей. В Kubernetes есть интеграция через специальный оператор, который синхронизирует секреты из Vault в кластер.

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

Главное правило: секреты не должны появляться в образах, коде и репозиториях. Все, что попало туда, считается скомпрометированным.

Заключение

Четыре описанных направления образуют базовый каркас защищенной контейнерной инфраструктуры. Каждое из них важно само по себе, но настоящая защита возникает только при их совместном применении: чистый образ не спасет, если сеть плоская; ограничение ресурсов не поможет, если секреты лежат в логах.

Внедрение этих практик требует изменений в процессах разработки и эксплуатации, но не требует фантастических бюджетов. Главное — применять меры безопасности системно, а не от случая к случаю.