Стратегия безопасности Kubernetes проваливается не потому, что в ней мало инструментов, а потому что она превращается в список пожеланий: «внедрить NetworkPolicy», «настроить мониторинг», «добавить сканирование». У такого списка нет владельца, порядка, критерия готовности и безопасного пути отката. Ниже — план, который переводит цикл статей в управляемую программу работ.
Он не является обязательным стандартом Kubernetes и не заменяет оценку рисков. Конкретный CNI, service mesh, registry, CI/CD и требования регулятора отличаются. Но для каждого этапа сохраняется один принцип: не объявлять контроль внедрённым, пока нет наблюдаемого результата и владельца его сопровождения.
Модель ответственности
Без разделения ролей платформа превращается в единственную точку ожиданий, а разработчики воспринимают безопасность как внешний запрет. Базовое распределение удобно зафиксировать до технических изменений.
| Роль | Отвечает за результат |
|---|---|
| Platform/SRE | CNI, кластеры, RBAC-границы, шаблоны, доступность контролей и rollback |
| Владелец сервиса | карта зависимостей, корректность workload-манифестов, функциональная проверка и устранение нарушений |
| Security/DevSecOps | модель угроз, требования к policy, исключения, supply-chain gates и контроль доказательств |
| SOC/дежурная команда | правила обнаружения, triage, runbook, эскалация и упражнения по инцидентам |
| Руководитель продукта/риска | приоритизация, принятие остаточного риска, выделение времени на исправления |
Один человек может совмещать роли в маленькой команде, но обязанность всё равно должна быть названа. Например, «владелец Platform» — лучше, чем «команда Kubernetes», если решение нужно принять ночью во время инцидента.
Этап 0. Зафиксировать исходное состояние
Цель. Понять, что именно защищается и какие изменения вообще допустимы.
Входы: перечень кластеров, namespaces и критичных сервисов; используемый CNI; способы входа/выхода трафика; service accounts; регистры образов; текущие логи, метрики и audit; требования к доступности.
Работа. Соберите карту «сервис → namespace → владельцы → зависимости → данные → внешний вход/выход». Не пытайтесь сразу описать каждый пакет. Достаточно выявить критичные потоки: пользователь → ingress → API, API → база, workload → DNS/внешний API, CI/CD → Kubernetes API. Отдельно отметьте системные namespaces: к ним нельзя применять прикладные правила без отдельной проверки.
Артефакт: версионируемый реестр сервисов и потоков, инвентарь текущих политик и известные исключения.
Контрольная точка: для каждого пилотного сервиса есть владелец и хотя бы один подтверждённый способ проверить его здоровое взаимодействие. Без этого запрещающие политики не вводятся.
Этап 1. Сделать изменения наблюдаемыми и обратимыми
Цель. До ужесточения иметь данные, которые объяснят отказ, и практический откат.
Работа. Включите централизованный сбор событий Kubernetes, логов приложения и минимальных сетевых наблюдений, доступных в выбранном CNI. Согласуйте единый набор полей для расследования: кластер, namespace, workload, Pod, service account, образ по digest, узел, время и идентификатор релиза. Создайте короткий runbook: кто смотрит отклонённый admission-запрос, где видно нарушение NetworkPolicy и как временно вернуть работоспособность без расширения прав навсегда.
Артефакт: дашборд/запросы для пилота, запись проверенного rollback и контакт дежурного.
Контрольная точка: команда может отличить «сервис не запустился из-за PSA» от «сервис не подключается из-за NetworkPolicy» за согласованное время. Если это неизвестно, следующим этапом будет неконтролируемый поиск причины.
Этап 2. Пилот минимальных сетевых прав
Цель. Ввести allow-list без риска заблокировать весь кластер.
Работа. Выберите один namespace с понятными зависимостями. Сначала подтвердите, что CNI действительно применяет Kubernetes NetworkPolicy; сам объект NetworkPolicy без поддержки провайдера не создаёт защиту. Затем добавьте default deny для пилотного namespace и минимальные правила: DNS, нужные входящие сервисы, нужные исходящие зависимости. Каждое правило должно ссылаться на владельца сервиса и проверяемую потребность, а не на догадку по IP.
Проверка: разрешённый сценарий работает; заранее выбранный запрещённый сценарий не проходит; события и поток видны в телеметрии. Выполните проверку до и после изменения, чтобы не принять случайный кэш за доказательство.
Контрольная точка: нет неучтённых широких 0.0.0.0/0 и «разрешить всё» в пилоте, кроме документированных временных исключений с датой удаления.
Этап 3. Укрепить входящий и исходящий периметр
Цель. Сделать ingress и egress управляемыми, а не побочным эффектом Service/LoadBalancer.
Работа. Определите, кто вправе создавать внешние точки входа, какие hostnames/TLS-сертификаты разрешены и как проверяется маршрут до backend. Для egress составьте реестр внешних направлений с бизнес-владельцем и способом идентификации: имя сервиса, gateway или другой механизм выбранного CNI. Не обещайте доменную фильтрацию, если конкретная реализация NetworkPolicy её не умеет.
Артефакт: правила входа и выхода, схема DNS/egress gateway, процедура добавления нового направления.
Контрольная точка: внешнее направление можно связать с workload и владельцем; неизвестный workload не получает широкий выход только потому, что он находится в «доверенном» namespace.
Этап 4. Ограничить способ запуска и происхождение образов
Цель. Не допускать небезопасный Pod и непонятный образ в production.
Работа. Сначала включите Pod Security Admission в режимах warn и audit для пилотного namespace, исправьте шаблоны Deployment/Job, затем включите enforce с закреплённой версией политики. Параллельно договоритесь о registry, digest, сканировании и сроках исключений. Admission-политики для registry/подписей вводите поэтапно: аудит → исправление → блокировка.
Проверка: тестовый манифест с запрещённым securityContext отклоняется; корректный workload запускается; отчёт CI связывается с digest работающего Pod. Это важнее, чем формальное наличие PSA labels.
Контрольная точка: исключения видимы, имеют владельца и срок; блокирующие правила не применены к системным или legacy-нагрузкам без проверенного плана миграции.
Этап 5. Добавить идентичность и шифрование там, где это обосновано
Цель. Защитить чувствительный сервисный трафик без ложного ощущения, что mTLS решает всё.
Работа. Для сервисов с высокой ценностью данных выберите модель: шифрование CNI, TLS приложения или конкретный service mesh. Зафиксируйте владельца PKI, модель идентичности workload, ротацию и наблюдаемость. Миграцию выполняйте на одном сервисном контуре; если продукт поддерживает переходный режим, используйте его только для инвентаризации plaintext-клиентов и с конечной датой.
Контрольная точка: разрешённый клиент проходит с ожидаемой идентичностью и шифрованием, а неподходящий клиент не может выдать себя за него. При этом NetworkPolicy и прикладная авторизация остаются отдельными контролями.
Этап 6. Связать detection с реакцией
Цель. Сократить время от сигнала до понятного действия.
Работа. Выберите несколько высокоценных сценариев: запуск shell в production-контейнере, привилегированный Pod, неожиданный egress, использование неподходящего образа, необычный вызов Kubernetes API. Для каждого укажите качество сигнала, приоритет, куда он поступает, кому назначается и какую информацию нужно сохранить. Проведите tabletop или безопасное упражнение: пройти инцидент от алерта до фиксации digest и решения об изоляции.
Артефакт: runbooks, правила корреляции, журнал проведённого упражнения и список улучшений.
Контрольная точка: дежурный может найти владельца, образ и недавние изменения workload без доступа «cluster-admin» и без ручного опроса нескольких команд.
Этап 7. Расширять покрытие только после стабильности
Пилот не надо копировать на все namespaces одним коммитом. Расширяйте по волнам: похожие сервисы, затем более сложные, затем legacy. Для каждой волны повторяются те же входы, тесты и окно отката. Метрики прогресса должны описывать качество: доля namespaces с проверенным default deny, доля production workloads с digest и действующим PSA, число активных исключений, время triage и число неизвестных внешних направлений.
Финальный результат — не «кластер настроен», а работающий цикл: изменения проходят через проверяемый путь, нарушения видны, исключения не бессрочны, а владельцы могут безопасно развивать систему. Именно такая последовательность позволяет усилить Kubernetes без хрупкой миграции и без иллюзии, что один инструмент закрывает весь риск.
Официальные источники
- Kubernetes Security Checklist: https://kubernetes.io/docs/concepts/security/security-checklist/
- Kubernetes NetworkPolicy: https://kubernetes.io/docs/concepts/services-networking/network-policies/
- Kubernetes Pod Security Admission: https://kubernetes.io/docs/concepts/security/pod-security-admission/
- Kubernetes Auditing: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/
