openshift ingress egress что это
Все об OpenShift Egress. Часть 2
В первой части статьи про OpenShift Egress мы рассмотрели варианты организации фиксированных исходящих IP-адресов для POD в кластере. Но что делать, если надо предоставить доступ во внешние по отношению к кластеру сегменты сети, находящиеся в определенных VLAN?
Multus CNI
Как известно, по умолчанию у POD в Kubernetes есть один интерфейс, через который и происходит все взаимодействие с ним. Multus позволяет создать в POD несколько интерфейсов помимо определенного по умолчанию. Фактически Multus сам является CNI-Plugin’ом, в свою очередь управляющий вызовом других CNI-Plugin’ов. За это Multus называют CNI meta Plugin. То, что делает Multus, хорошо показано на картинке из статьи Demystifing Multus:
Разумеется, количество дополнительных интерфейсов может быть больше чем один.
Настройка Multus CNI в OpenShift
Итак, попробуем решить задачу доступа в выделенный VLAN на нашем стенде. По умолчанию всем узлам кластера выделен один интерфейс, находящийся в VLAN OpenShift (IP: 192.168.111/24). Мы хотим организовать доступ из проекта multes-test в ресурсы сети 192.168.112/24, находящейся в VLAN Restricted. VLAN Restricted и VLAN OpenShift между собой не маршрутизируются.
Для начала добавим на ряд узлов (в нашем случае это Node1 и Node2) интерфейс из VLAN Restricted, и поставим на этих узлах метку node-role.kubernetes.io/multus-node=’yes’. C узлов с меткой multus-node будут доступны ресурсы из Restricted VLAN. Создадим наш проект multus-test:
Поддержка Multus CNI давно присутствует в OpenShift, отдельно добавлять ее не надо. Управление конфигурацией Multus производится через CR в CRD networks.operator.openshift.io. Необходимо отредактировать этот ресурс, добавив конфигурацию CNI Plugin для нового интерфейса:
oc edit networks.operator.openshift.io cluster
Этот момент требует расшифровки. Что мы определили данной конфигурацией?
Выбор CNI Plugin
Для нашего дополнительного интерфейса нужно выбрать используемый CNI Plugin. Список возможных CNI Plugin можно посмотреть на сайте www.cni.dev. В своем примере мы используем ipvlan plugin. По сути это простейший bridge, который позволяет контейнерам взаимодействовать через внешний сетевой интерфейс хоста. При этом все исходящие соединения используют свой IP-адрес, но будут иметь MAC-адрес внешнего сетевого интерфейса. Картинка с сайта hicu.be хорошо иллюстрирует работу ipvlan plugin:
В продуктивных окружениях чаще выбирают macvlan plugin, который отличается от ipvlan тем, что исходящие соединения имеют уникальные MAC-адреса. Но в этом случае зачастую необходима подготовка сетевой инфраструктуры, чтобы сетевое оборудование позволило передачу пакетов с разными MAC-адресами с одного порта.
Выбор IPAM Plugin
Помимо организации сетевого интерфейса нам необходимо определить правила выдачи IP-адреса для нового интерфейса. Этим также занимается CNI Plugin, который реализует функции IP Address Management (или IPAM). Список возможных IPAM-plugin также можно посмотреть на сайте www.cni.dev. В данном примере мы использовали простейший static IPAM plugin, который присваивает фиксированный адрес нашему POD.
Если таких POD окажется много, использовать static IPAM станет неудобно. Хорошим выбором здесь будет либо использование dhcp plugin (он назначает IP адреса POD через запрос к внешнему DHCP-серверу), либо использование whereabouts plugin.
Поддержка этих IPAM Plugin также по умолчанию есть в OpenShift, отдельно устанавливать их не надо.
Доступ в restricted VLAN
После определения нашей конфигурации Multus в кластере должен появиться ресурс под названием Network Attachment Definition, в котором отражена текущая конфигурация Multus:
Network Attachment Definition
Создадим тестовый POD с дополнительным интерфейсом, который будет иметь доступ в наш restricted VLAN:
pod-ipvlan-static.yaml
Зайдем в созданный POD, чтобы посмотреть его сетевую конфигурацию и проверить доступность адресов в restricted VLAN (в сети 192.168.112.0/24):
Как видно из вывода команды «ip a», POD получил дополнительный сетевой интерфейс net1@if826 и IP-адрес, который мы указали в его манифесте. Так как дополнительный интерфейс работает через ethernet адаптер, находящийся в restricted VLAN, с этого POD мы получили доступ в нужный нам сегмент сети.
Автор: Сергей Артемов, руководитель отдела DevOps-решений «Инфосистемы Джет»
Присоединяйтесь к нашему каналу в Telegram @DevSecOps Talks!
Ingress Operator in OpenShift Container Platform
The Ingress Operator implements the ingresscontroller API and is the component responsible for enabling external access to OpenShift Container Platform cluster services. The operator makes this possible by deploying and managing one or more HAProxy-based Ingress Controllers to handle routing. You can use the Ingress Operator to route traffic by specifying OpenShift Container Platform Route and Kubernetes Ingress resources.
The Ingress configuration asset
The installation program stores this asset in the cluster-ingress-02-config.yml file in the manifests/ directory. This Ingress resource defines the cluster-wide configuration for Ingress. This Ingress configuration is used as follows:
The Ingress Operator uses the domain from the cluster Ingress configuration as the domain for the default Ingress Controller.
The OpenShift API server operator uses the domain from the cluster Ingress configuration as the domain used when generating a default host for a Route resource that does not specify an explicit host.
Ingress controller configuration parameters
The ingresscontrollers.operator.openshift.io resource offers the following configuration parameters.
domain is a DNS name serviced by the Ingress controller and is used to configure multiple features:
The value is published to individual Route statuses so that users know where to target external DNS records.
The domain value must be unique among all Ingress controllers and cannot be updated.
endpointPublishingStrategy is used to publish the Ingress controller endpoints to other networks, enable load balancer integrations, and provide access to other systems.
AWS: LoadBalancerService (with external scope)
Azure: LoadBalancerService (with external scope)
GCP: LoadBalancerService (with external scope)
The endpointPublishingStrategy value cannot be updated.
The defaultCertificate value is a reference to a secret that contains the default certificate that is served by the Ingress controller. When Routes do not specify their own certificate, defaultCertificate is used.
The secret must contain the following keys and data: * tls.crt : certificate file contents * tls.key : key file contents
The in-use certificate, whether generated or user-specified, is automatically integrated with OpenShift Container Platform built-in OAuth server.
namespaceSelector is used to filter the set of namespaces serviced by the Ingress controller. This is useful for implementing shards.
routeSelector is used to filter the set of Routes serviced by the Ingress controller. This is useful for implementing shards.
nodePlacement enables explicit control over the scheduling of the Ingress controller.
If not set, the defaults values are used.
All parameters are optional.
Ingress controller endpoint publishing strategy
An Ingress controller with the HostNetwork endpoint publishing strategy can have only one Pod replica per node. If you want n replicas, you must use at least n nodes where those replicas can be scheduled. Because each Pod replica requests ports 80 and 443 on the node host where it is scheduled, a replica cannot be scheduled to a node if another Pod on the same node is using those ports.
View the default Ingress Controller
The Ingress Operator is a core feature of OpenShift Container Platform and is enabled out of the box.
Every new OpenShift Container Platform installation has an ingresscontroller named default. It can be supplemented with additional Ingress Controllers. If the default ingresscontroller is deleted, the Ingress Operator will automatically recreate it within a minute.
View the default Ingress Controller:
View Ingress Operator status
You can view and inspect the status of your Ingress Operator.
View your Ingress Operator status:
View Ingress Controller logs
You can view your Ingress Controller logs.
View your Ingress Controller logs:
View Ingress Controller status
Your can view the status of a particular Ingress Controller.
View the status of an Ingress Controller:
Setting a custom default certificate
As an administrator, you can configure an Ingress Controller to use a custom certificate by creating a Secret resource and editing the IngressController custom resource (CR).
You must have a certificate/key pair in PEM-encoded files, where the certificate is signed by a trusted certificate authority and valid for the Ingress domain.
You must have an IngressController CR. You may use the default one:
If the default certificate is replaced, it must be signed by a public certificate authority already included in the CA bundle as provided by the container userspace.
If you have intermediate certificates, they must be included in the tls.crt file of the secret containing a custom default certificate. Order matters when specifying a certificate; list your intermediate certificate(s) after any server certificate(s).
This action will cause the Ingress Controller to be redeployed, using a rolling deployment strategy.
Create a Secret resource containing the custom certificate in the openshift-ingress namespace using the tls.crt and tls.key files.
Update the IngressController CR to reference the new certificate secret:
Введение в сетевые политики Kubernetes для специалистов по безопасности
Прим. перев.: Автор статьи — Reuven Harrison — имеет более 20 лет опыта в разработке программного обеспечения, а на сегодняшний день является техническим директором и соучредителем компании Tufin, создающей решения для управления политиками безопасности. Рассматривая сетевые политики Kubernetes как достаточно мощное средство для сегментации сети в кластере, он в то же время считает, что они не так просты в применении на практике. Данный материал (довольно объёмный) призван улучшить осведомлённость специалистов в этом вопросе и помочь им в создании необходимых конфигураций.
Сегодня многие компании все чаще выбирают Kubernetes для запуска своих приложений. Интерес к этому ПО настолько высок, что некоторые называют Kubernetes «новой операционной системой для центров обработки данных». Постепенно Kubernetes (или k8s) начинает восприниматься как критически важная часть бизнеса, которая требует организации зрелых бизнес-процессов, в том числе обеспечения сетевой безопасности.
Для специалистов по безопасности, которых озадачили работой с Kubernetes, настоящим открытием может стать политика этой платформы по умолчанию: разрешить всё.
Это руководство поможет разобраться во внутреннем устройстве сетевых политик; понять, чем они отличаются от правил для обычных брандмауэров. Также будет рассказано о некоторых подводных камнях и будут даны рекомендации, которые помогут защитить приложения в Kubernetes.
Сетевые политики Kubernetes
Механизм сетевых политик Kubernetes позволяет управлять взаимодействием развернутых на платформе приложений на сетевом уровне (третьем в модели OSI). Сетевые политики лишены некоторых передовых функций современных брандмауэров, таких как контроль на 7 уровне OSI и обнаружение угроз, однако они обеспечивают базовый уровень сетевой безопасности, выступающий неплохой отправной точкой.
Сетевые политики контролируют коммуникации между pod’ами
Рабочие нагрузки в Kubernetes распределяются по pod’ам, которые состоят из одного или нескольких контейнеров, развернутых совместно. Kubernetes присваивает каждому pod’у IP-адрес, доступный из других pod’ов. Сетевые политики Kubernetes задают права доступа для групп pod’ов таким же образом, как группы безопасности в облаке используются для управления доступом к экземплярам виртуальных машин.
Определение сетевых политик
Как и остальные ресурсы Kubernetes, сетевые политики задаются на языке YAML. В приведенном ниже примере приложению balance открывается доступ к postgres :
(Прим. перев.: этот скриншот, как и все последующие аналогичные, создан не родными средствами Kubernetes, а с помощью инструмента Tufin Orca, за разработкой которого стоит компания автора оригинальной статьи и который упоминается в конце материала.)
Для определения собственной сетевой политики потребуются базовые знания YAML. Этот язык основан на отступах (задаваемых пробелами, а не табуляцией). Элемент с отступом принадлежит ближайшему элементу с отступом над ним. Новый элемент списка начинается с дефиса, все остальные элементы имеют вид ключ-значение.
Описав политику на YAML, используйте kubectl, чтобы создать ее в кластере:
Спецификация сетевой политики
Спецификация сетевой политики Kubernetes включает в себя четыре элемента:
В соответствии с приведенной выше логикой в случае, если параметры ingress и/или egress опущены, политика будет запрещать весь трафик (см. «Правило зачистки» ниже).
Политика по умолчанию — разрешить
Если политики не определены, Kubernetes по умолчанию разрешает весь трафик. Все pod’ы свободно могут обмениваться информацией между собой. С точки зрения безопасности это может показаться нелогичным, но вспомните о том, что Kubernetes изначально создавался разработчиками с целью обеспечить взаимодействие приложений. Сетевые политики были добавлены позже.
Пространства имен
Пространства имен (Namespaces) — механизм коллективной работы Kubernetes. Они предназначены для изолирования логических окружений друг от друга, при этом обмен данными между пространствами по умолчанию разрешен.
Как и большинство компонентов Kubernetes, сетевые политики обитают в определенном пространстве имен. В блоке metadata можно прописать, какому именно пространству принадлежит политика:
Если пространство имен в метаданных явно не прописано, система будет использовать namespace, указанное в kubectl (по умолчанию namespace=default ):
Я рекомендую явно указывать namespace, если только вы не пишете политику, предназначенную сразу для нескольких пространств имен.
Основной элемент podSelector в политике будет выбирать pod’ы из пространства имен, к которому принадлежит политика (он лишен доступа к pod’ам из другого пространства имён).
Аналогичным образом podSelector’ы в блоках ingress и egress могут выбирать pod’ы только из своего пространства имен, если, конечно, вы не объедините их с помощью namespaceSelector (об этом пойдет речь в разделе «Фильтр по пространствам имен и pod’ам»).
Правила именования политик
Названия политик уникальны в рамках одного пространства имен. Двух политик с одинаковым названием в одном пространстве быть не может, но могут быть политики с одинаковыми названиями в разных пространствах. Это удобно, когда вы хотите повторно применить одну и ту же политику на нескольких пространствах.
Мне особенно нравится один из способов именования. Он состоит в том, чтобы объединять название пространства имен с целевыми pod’ами. Например:
Лейблы
К объектам Kubernetes, таким как pod’ы и пространства имен, можно прикреплять пользовательские лейблы. Лейблы (labels — метки) являются эквивалентом тегов в облаке. Сетевые политики Kubernetes используют лейблы для выбора pod’ов, к которым они применяются:
… или пространств имен, к которым они применяются. В этом примере выбираются все pod’ы в пространствах имен с соответствующими лейблами:
Добавить лейбл к пространству можно следующим образом:
При этом namespace в разделе metadata должен ссылаться на фактическое имя пространства, а не на лейбл:
Источник и адресат
Политики для брандмауэров состоят из правил с источниками и адресатами. Сетевые политики Kubernetes определяются для цели — набора из pod’ов, к которым они применяются, а затем устанавливают правила для входящего (ingress) и/или исходящего (egress) трафика. В нашем примере целью политики будут все pod’ы в пространстве имен default с лейблом с ключом app и значением db :
Подраздел ingress в этой политике открывает входящий трафик к целевым pod’ам. Другими словами, ingress выступает источником, а цель — соответствующим адресатом. Аналогичным образом egress является адресатом, а цель — его источником.
Это эквивалентно двум правилам для брандмауэра: Ingress → Цель; Цель → Egress.
Egress и DNS (важно!)
Ограничивая исходящий трафик, особое внимание обратите на DNS — Kubernetes использует эту службу для сопоставления сервисов с IP-адресами. Например, следующая политика не сработает, поскольку вы не разрешили приложению balance обращаться к DNS:
Исправить ее можно, открыв доступ к сервису DNS:
Последний элемент to — пустой, и поэтому он косвенно выбирает все pod’ы во всех пространствах имен, позволяя balance посылать DNS-запросы в соответствующую службу Kubernetes (обычно она работает в пространстве kube-system ).
Этот подход работает, однако он чрезмерно разрешающий и небезопасный, поскольку позволяет направлять DNS-запросы за пределы кластера.
Улучшить его можно тремя последовательными шагами.
1. Разрешить DNS-запросы только внутри кластера, добавив namespaceSelector :
Для этого нужно добавить лейбл в пространство имен kube-system : kubectl label namespace kube-system namespace=kube-system — и прописать ее в политике с помощью namespaceSelector :
Другой вариант — разрешить DNS на уровне пространства имен. В этом случае его не нужно будет открывать для каждой службы:
Пустой podSelector выбирает все pod’ы в пространстве имен.
Первое соответствие и порядок правил
В обычных брандмауэрах действие («Разрешить» или «Запретить») в отношении пакета определяется первым правилом, которому он удовлетворяет. В Kubernetes порядок политик не имеет никакого значения.
По умолчанию, когда политики не заданы, коммуникации между pod’ами разрешены и они могут свободно обмениваться информацией. Как только вы начинаете формулировать политики, каждый pod, затронутый хотя бы одной из них, становится изолированным в соответствии с дизъюнкцией (логическим ИЛИ) всех политик, которые его выбрали. Pod’ы, не затронутые какой-либо политикой, остаются открытыми.
Изменить подобное поведение можно с помощью правила зачистки.
Правило зачистки («Запретить»)
Политики брандмауэров обычно запрещают любой явным образом не разрешенный трафик.
В Kubernetes нет действия «запретить» (deny), однако аналогичного эффекта можно добиться с обычной (разрешающей) политикой, выбрав пустую группу pod’ов-источников (ingress):
Эта политика выбирает все pod’ы в пространстве имен и оставляет ingress неопределенным, запрещая весь входящий трафик.
Похожим образом можно ограничить весь исходящий трафик из пространства имен:
Учтите, что любые дополнительные политики, разрешающие трафик к pod’ам в пространстве имен, будут иметь приоритет над этим правилом (аналогично добавлению разрешающего правила перед запрещающим в конфигурации брандмауэра).
Разрешить все (Any-Any-Any-Allow)
Чтобы создать политику «Разрешить все», необходимо дополнить приведенную выше запретительную политику пустым элементом ingress :
Правило можно сузить и разрешить доступ только к определенному набору pod’ов ( app:balance ) в пространстве имен default :
Следующая политика разрешает весь входящий (ingress) И исходящий (egress) трафик, включая доступ к любому IP за пределами кластера:
Объединение нескольких политик
Политики объединяются с помощью логического ИЛИ на трех уровнях; разрешения каждого pod’а устанавливаются в соответствии с дизъюнкцией всех политик, которые его затрагивают:
1. В полях from и to можно определить три типа элементов (все они комбинируются с помощью ИЛИ):
2. Внутри политики раздел ingress может иметь множество элементов from (объединяются логическим ИЛИ). Аналогичным образом раздел egress может включать множество элементов to (также объединяются дизъюнкцией):
3. Различные политики также объединяются логическим ИЛИ
Но при их объединении существует одно ограничение, на которое указал Chris Cooney: Kubernetes может комбинировать политики только с различными policyTypes ( Ingress или Egress ). Политики, определяющие ingress (или egress), перезапишут друг друга.
Связь между пространствами имен
По умолчанию обмен информацией между пространствами имен разрешен. Изменить это можно с помощью запретительной политики, которая ограничит исходящий и/или входящий трафик в пространство имен (см. «Правило зачистки» выше).
Заблокировав доступ в пространство имен (см. «Правило зачистки» выше), вы можете внести исключения в запретительную политику, разрешив подключения с определенного пространства имен с помощью namespaceSelector :
Фильтр по пространствам имен И pod’ам
Kubernetes версии 1.11 и выше позволяет комбинировать операторы namespaceSelector и podSelector с помощью логического И. Выглядит это следующим образом:
Почему это трактуется как И вместо привычного ИЛИ?
Обратите внимание, что podSelector не начинается с дефиса. В YAML это означает, что podSelector и стоящий перед ним namespaceSelector относятся к одному и тому же элементу списка. Поэтому они объединяются логическим И.
Добавление дефиса перед podSelector приведет к возникновению нового элемента списка, который будет комбинироваться с предшествующим namespaceSelector с помощью логического ИЛИ.
Чтобы выбрать pod’ы с определенным лейблом во всех пространствах имен, впишите пустой namespaceSelector :
Множественные лейблы объединяются с И
Правила для брандмауэра со множеством объектов (хостами, сетями, группами) комбинируются с помощью логического ИЛИ. Следующее правило сработает, если источник пакета совпадает с Host_1 ИЛИ Host_2 :
Наоборот, в Kubernetes различные лейблы в podSelector или namespaceSelector объединяются логическим И. Например, следующее правило выберет pod’ы, обладающие обеими лейблами, role=db И version=v2 :
Та же логика применяется ко всем типам операторов: селекторам целей политики, селекторам pod’ов и селекторам пространств имен.
Подсети и IP-адреса (IPBlocks)
Для сегментирования сети брандмауэры используют VLAN, IP-адреса и подсети.
В Kubernetes IP-адреса присваиваются pod’ам автоматически и могут часто меняться, поэтому для выбора pod’ов и пространств имен в сетевых политиках используются лейблы.
Подсети ( ipBlocks ) используются при управлении входящими (ingress) или исходящими (egress) внешними (North-South) подключениями. К примеру, эта политика открывает всем pod’ам из пространства имен default доступ к DNS-сервису Google:
Пустой селектор pod’ов в этом примере означает «выбрать все pod’ы в пространстве имен».
Данная политика открывает доступ только к 8.8.8.8; доступ к любому другому IP запрещен. Таким образом, по сути, вы заблокировали доступ к внутренней службе DNS Kubernetes. Если вы все же хотите его открыть, укажите это явно.
В качестве контр-примера следующая политика включает все IP и, следовательно, разрешает доступ ко всем другим pod’ам:
Можно открыть доступ только к внешним IP, исключив внутренние IP-адреса pod’ов. Например, если подсеть вашего pod’а 10.16.0.0/14:
Порты и протоколы
Обычно pod’ы слушают один порт. Это означает, что можно просто не указывать номера портов в политиках и оставить все по умолчанию. Впрочем, политики рекомендуется делать максимально ограничительными, поэтому в некоторых случаях все же можно указывать порты:
Работа портов по умолчанию:
Обратите внимание, что необходимо использовать порты pod’ов, а не сервисов (подробнее об этом в следующем параграфе).
Политики определены для pod’ов или сервисов?
Обычно pod’ы в Kubernetes обращаются друг к другу через сервис — виртуальный балансировщик нагрузки, перенаправляющий трафик к pod’ам, реализующим сервис. Можно подумать, что сетевые политики контролируют доступ к сервисам, но это не так. Сетевые политики Kubernetes работают с портами pod’ов, а не сервисов.
Например, если сервис слушает 80-й порт, но перенаправляет трафик на порт 8080 своих pod’ов, в сетевой политике необходимо указать именно 8080.
Подобный механизм следует признать неоптимальным: при изменении внутреннего устройства сервиса (порты которого слушают pod’ы) придется обновлять сетевые политики.
Новый архитектурный подход с использованием Service Mesh (например, см. про Istio ниже — прим. перев.) позволяет справиться с этой проблемой.
Необходимо ли прописывать как Ingress, так и Egress?
Короткий ответ — да, чтобы pod А мог связаться с pod’ом В, необходимо разрешить ему создавать исходящее соединение (для этого следует настроить egress-политику), а pod В должен иметь возможность принимать входящее соединение (для этого, соответственно, нужна ingress-политика).
Однако на практике можно положиться на политику по умолчанию, разрешающую соединения в одном или обоих направлениях.
Если некий pod-источник будет выбран одной или несколькими egress-политиками, накладываемые на него ограничения будут определяться их дизъюнкцией. В этом случае потребуется явно разрешить подключение к pod’у-адресату. Если pod не выбран какой-либо политикой, его исходящий (egress) трафик разрешен по умолчанию.
Аналогичным образом судьба pod’а-адресата, выбранного одной или несколькими ingress-политиками, будет определяться их дизъюнкцией. В этом случае необходимо явно разрешить ему получать трафик от pod’а-источника. Если pod не выбран какой-либо политикой, весь входящий (ingress) трафик для него разрешен по умолчанию.
См. пункт «Stateful или Stateless» ниже.
Сетевые политики Kubernetes не умеют журналировать трафик. Это затрудняет определение того, работает ли политика должным образом, и сильно осложняет анализ в области безопасности.
Контроль за трафиком к внешним сервисам
Сетевые политики Kubernetes не позволяют указывать полноценное доменное имя (DNS) в разделах egress. Этот факт приводит к значительному неудобству при попытке ограничить трафик к внешним адресатам, лишенным фиксированного IP-адреса (таким как aws.com).
Проверка политики
Брандмауэры предупредят вас или даже откажутся принять ошибочную политику. Kubernetes тоже проводит некоторую верификацию. При задании сетевой политики через kubectl Kubernetes может заявить, что она неверна, и отказаться ее принять. В других случаях Kubernetes примет политику и дополнит ее недостающими деталями. Их можно увидеть с помощью команды:
Имейте в виду, что система проверки Kubernetes не непогрешима и может пропускать некоторые типы ошибок.
Исполнение
Kubernetes не занимается реализацией сетевых политик самостоятельно, а является лишь API-шлюзом, возлагающим обременительную работу по контролю на нижележащую систему, называемую Container Networking Interface (CNI). Задание политик в кластере Kubernetes без назначения соответствующего CNI аналогично созданию политик на сервере управления брандмауэром без их последующей установки в брандмауэры. Вы сами должны убедиться в наличии достойного CNI или, в случае платформ Kubernetes, размещенных в облаке (со списком провайдеров можно ознакомиться здесь — прим. пер.), задействовать сетевые политики, которые установят CNI для вас.
Обратите внимание, что Kubernetes не предупредит вас, если вы зададите сетевую политику без соответствующего вспомогательного CNI.
Stateful или Stateless?
Все CNI Kubernetes, с которыми мне доводилось сталкиваться, хранят состояния (например, Calico использует Linux conntrack). Это позволяет pod’у получать ответы по инициированному им TCP-соединению без необходимости устанавливать его заново. При этом мне неизвестно о стандарте Kubernetes, который гарантировал бы хранение состояния (statefulness).
Продвинутое управление политикой безопасности
Вот несколько способов повысить эффективность исполнения политики безопасности в Kubernetes:
Дополнительная информация
Заключение
Сетевые политики Kubernetes предлагают неплохой набор инструментов для сегментации кластеров, однако они интуитивно непонятны и имеют множество тонкостей. Я считаю, что из-за этой сложности политики многих существующих кластеров содержат ошибки. Возможными решениями этой проблемы являются автоматизация определений политик или применение других средств сегментации.
Надеюсь, что это руководство поможет прояснить некоторые вопросы и решить проблемы, с которыми вы можете столкнуться.