Сетевую сегментацию проще понять не через определения, а через сценарий атаки.
Представим интернет-магазин:
Internet
|
frontend
|
backend
|
database
Frontend опубликован наружу. В нём обнаруживается уязвимость, позволяющая выполнить команду внутри контейнера.
Что происходит дальше?
Первый этап: выполнение кода в контейнере
Нарушитель уже находится внутри workload.
Это ещё не означает компрометацию Kubernetes. На этом этапе он действует примерно как на обычном Linux-сервере, но внутри ограниченного окружения контейнера.
Его интересуют переменные окружения, конфигурационные файлы, доступные сетевые сервисы, DNS, mounted secrets, ServiceAccount token и возможность обращения к Kubernetes API.
Второй этап: исследование сети
Если east-west не ограничен, скомпрометированный frontend может видеть больше сервисов, чем требуется бизнес-логике.
Например:
frontend
+-- backend
+-- database
+-- redis
+-- internal-admin-api
+-- monitoring
Для работы frontend, возможно, нужен только backend.
Все остальные связи увеличивают blast radius.
Lateral movement
Lateral movement — перемещение от первой скомпрометированной точки к другим системам.
В Kubernetes это может быть:
frontend → backend → database
или:
frontend → internal service → external infrastructure
NetworkPolicy не предотвращает сам первоначальный взлом приложения, но способна существенно ограничить следующий шаг.
Blast radius
Blast radius — масштаб потенциальных последствий одной компрометации.
Если один pod может обращаться ко всему кластеру и в Интернет, blast radius большой.
Если pod видит только один backend и DNS, он заметно меньше.
Это один из главных смыслов микросегментации.
ServiceAccount
Pod может иметь ServiceAccount token.
Этот токен используется для аутентификации в Kubernetes API.
Но важно понимать:
ServiceAccount token не равен правам администратора.
Фактические возможности определяет RBAC.
Хорошая конфигурация:
frontend ServiceAccount
|
+-- нет доступа к Secrets
+-- нет создания Pod
+-- нет изменения NetworkPolicy
+-- нет ClusterRoleBinding
Плохая конфигурация:
frontend ServiceAccount
|
cluster-admin
В последнем случае обычная уязвимость приложения может превратиться в серьёзную компрометацию управления.
Нужно ли монтировать токен вообще
Если приложение не использует Kubernetes API, ему часто не нужен ServiceAccount token.
Можно использовать:
automountServiceAccountToken: false
Это уменьшает количество credentials внутри контейнера.
Попытка выхода на node
Следующий уровень — попытка выйти за границы контейнера.
Риск возрастает, если workload запускается privileged, с hostNetwork, с hostPID, с опасными capabilities, с hostPath или с доступом к container runtime socket.
Поэтому NetworkPolicy нельзя рассматривать отдельно от Pod Security.
Что будет при компрометации node
Если нарушитель получил контроль над worker node, последствия существенно серьёзнее.
На node могут находиться pod разных приложений. Кроме того, node является частью инфраструктуры управления кластером.
Именно поэтому высокопривилегированные и недоверенные workload не следует смешивать без необходимости.
Supply chain
Есть и другой сценарий: вредоносный код попадает в контейнер ещё до запуска.
Например, через скомпрометированную зависимость, CI/CD, container registry или подменённый image.
В этом случае Kubernetes честно запустит уже проблемный workload.
Удаление pod не поможет: новый будет создан из того же image.
Это показывает, почему безопасность Kubernetes состоит из нескольких слоёв.
Модель эшелонированной защиты
Supply chain
↓
Admission
↓
Pod Security
↓
NetworkPolicy
↓
RBAC
↓
Runtime detection
↓
SIEM/SOC
Ни один слой не заменяет остальные.
Простой пример правильной минимизации
Пусть frontend должен только:
- принимать запросы через ingress;
- обращаться к backend на TCP/8080;
- использовать DNS.
Тогда его сеть должна примерно соответствовать этой логике.
Не нужно заранее разрешать ему БД, мониторинг и весь Интернет «на случай необходимости».
Что проверять
Для каждого критичного workload полезно ответить:
- Какие входящие соединения ему действительно нужны?
- Куда он действительно должен ходить?
- Нужен ли ему Kubernetes API?
- Какие Secrets он получает?
- Какие capabilities используются?
- Есть ли hostPath/hostNetwork?
- Что произойдёт, если этот workload будет полностью скомпрометирован?
Последний вопрос особенно полезен.
Защищённая архитектура предполагает компрометацию одного компонента и пытается не позволить ей автоматически стать компрометацией всей системы.
В следующей статье перейдём к основному встроенному механизму сетевой сегментации Kubernetes — NetworkPolicy.