Поды Kubernetes по умолчанию могут свободно общаться друг с другом.
Это создает риск безопасности, когда ваш кластер используется для нескольких приложений или команд.
Ошибочное поведение или злонамеренный доступ в одном поды может направить трафик на другие поды в вашем кластере.
В этой статье мы расскажем вам, как избежать этого сценария путем настройки сетевых политик.
Как упростить управление Kubernetes с помощью контекстов Kubectl
Эти правила позволяют контролировать потоки трафика между подами на уровне IP-адресов (уровень OSI 3 или 4).
Вы можете точно определить источники входящего и исходящего трафика, разрешенные для каждого пода.
🐳 Популярные ошибки в конфигурации, которые делают контейнерные приложения уязвимыми для атак
- Создание сетевой политики
- Принцип работы сетевых политик
- Примеры сетевых политик
- Применить политику к каждому поду в пространстве имен, разрешая входящий трафик только из определенного блока IP-адресов.
- Разрешить входящий трафик из блока IP-адресов, но исключить некоторые определенные IP-адреса
- Разрешить входящий трафик со всех подсистем в пространстве имен, но только с определенного порта
- Разрешить трафик из подов с определенным тегом, которые существуют в другом пространстве имен
- Явное разрешение всего трафика
- Когда использовать сетевые политики
- Заключение
Создание сетевой политики
Сетевые политики создаются путем добавления объектов NetworkPolicy в кластер.
Каждая политика определяет поды, к которым она применяется, и одно или несколько правил ingess и egress.
Вот базовый манифест политики:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: network-policy
namespace: app
spec:
podSelector:
matchLabels:
component: database
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector:
matchLabels:
component: api
egress:
- to:
- podSelector:
matchLabels:
component: api
Эта сетевая политика применяется к любому поду с меткой component: database в пространстве имен app.
Она гласит, что входящий (ingress) и исходящий (egress) трафик разрешен только от и к поду с меткой component: api.
Любые запросы, исходящие от других подов, например, component: web-frontend, будут блокироваться.
Сетевые политики могут быть применены, как и любой другой объект, с помощью Kubectl.
Они вступят в силу сразу после создания.
Вы можете добавить сетевую политику до запуска выбранных ею подов.
Принцип работы сетевых политик
Сетевые политики реализуются плагином активной сети вашего кластера.
Ваши политики не будут иметь никакого эффекта, если ваш плагин не поддерживает эту функцию.
Большинство популярных вариантов, таких как Calico и Cilium, поставляются с включенной поддержкой сетевых политик.
Когда сетевая политика применяется к поду, плагин проверяет его трафик на соответствие требованиям политики.
Любые соединения, которые не соответствуют критериям, будут запрещены.
Под, который пытался инициировать соединение, обнаружит, что удаленный хост недоступен, либо потому что он пытался получить доступ к ресурсу, заблокированному правилом egress, либо потому что удаленный под запретил входящее соединение с помощью правила ingress.
Успешное соединение между двумя подами может быть установлено только тогда, когда сетевые политики обеих подов разрешают его.
Соединение может быть запрещено правилом egress инициирующего пода или правилом ingress целевого пода.
Сетевые политики всегда аддитивны по своей природе. Когда несколько политик выбирают один и тот же Pod, список разрешенных источников входа и выхода будет представлять собой комбинацию всех политик.
Примеры сетевых политик
Сетевые политики поддерживают множество различных опций для настройки целевых подсистем и типов разрешенных соединений.
Следующие примеры демонстрируют несколько распространенных случаев использования.
Применить политику к каждому поду в пространстве имен, разрешая входящий трафик только из определенного блока IP-адресов.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: network-policy
namespace: app
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
Пустой блок podSelector означает, что политика нацелена на все поды пространства имен.
Правило ipBlock ограничивает входящий трафик для подов с IP-адресом в указанном диапазоне.
Исходящий трафик не блокируется.
Разрешить входящий трафик из блока IP-адресов, но исключить некоторые определенные IP-адреса
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: network-policy
namespace: app
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.0.1/24
- 172.17.0.2/24
- 172.17.0.3/24
Правила ipBlock поддерживают поле except для исключения трафика, исходящего от определенных IP-адресов или направленного на них.
Разрешить входящий трафик со всех подсистем в пространстве имен, но только с определенного порта
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: network-policy
namespace: app
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- podSelector: {}
ports:
- protocol: TCP
port: 443
Поле порты доступно для правил входа и выхода.
Оно определяет порты, с которых может приниматься и на которые может отправляться трафик.
Вы можете дополнительно указать диапазон портов, например 3000 – 3500, задав поле endPort (3500) в дополнение к port (3000).
Разрешить трафик из подов с определенным тегом, которые существуют в другом пространстве имен
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: network-policy
namespace: database
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
application: demo-app
podSelector:
matchLabels:
component: database
Политика гласит, что любой под с меткой (тегом) component: database может достичь всех подов в пространстве имен database, если его собственное пространство имен имеет метку demo-app.
Вы можете разрешить трафик от всех подов во внешнем пространстве имен, создав правило, включающее только поле namespaceSelector.
Явное разрешение всего трафика
Иногда вы можете захотеть явно разрешить весь трафик определенного типа в пространстве имен.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: network-policy
namespace: app
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
ingress:
- {}
egress:
- {}
Все поды в пространстве имен могут свободно общаться, как если бы политики не было.
Создание политики в любом случае позволяет вам сообщить о своих намерениях другим пользователям кластера.
Они могут усомниться в наличии пространства имен с неограниченным сетевым взаимодействием в кластере, который в противном случае был бы защищен.
Когда использовать сетевые политики
Сетевые политики должны быть созданы для каждого пространства имен и подов в вашем кластере.
Это позволит лучше изолировать ваши поды и обеспечить контроль над потоком трафика.
Постарайтесь сделать ваши политики настолько гранулированными, насколько это возможно.
Слишком широкое расширение доступа, например, разрешение доступа между всеми подами в пространстве имен, оставляет вас в опасности, если один из ваших контейнеров будет взломан.
Kubernetes не включает сетевые политики по умолчанию, что может привести к ошибкам, даже если вы планируете, что все поды будут защищены политикой.
Вы можете снизить этот риск, добавив в пространство имен универсальную политику.
Эта политика выбирает каждый поды в пространстве имен и применяет правило, запрещающее любое сетевое взаимодействие:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: app
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
Сетевые политики всегда привязаны к пространствам имен
Заключение
Kubernetes позволяет всем подам в вашем кластере общаться друг с другом.
Для реальных приложений, работающих в многоцелевых кластерах, это слишком большая свобода действий.
Сетевые политики решают эту проблему, предоставляя систему, подобную брандмауэру, для управления входящими источниками и исходящими целями, которые принимает каждый пода.
см. также:
