Погружение в Kubernetes Network Policies

Привет, Хабр! Меня зовут Сулейман, и я Senior Software Engineer более чем с 10 годами опыта в программировании. Я разрабатываю сложные веб-сервисы, способные масштабироваться и выдерживать высокие нагрузки, а также активно участвую в open source проектах, публикую статьи, связанные с разработкой, и видео по решению алгоритмических задач. Я являюсь сертифицированным Kubernetes Application Developer (CKAD), и мой опыт охватывает различные сферы разработки: от бэкенда и фронтенда до DevOps и разработки Android-приложений. Больше моих статей можно найти в меди вАЙТИ.

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

Что такое Network Policies?

Network Policies — это абстракция, позволяющая определять правила сетевого взаимодействия между объектами в кластере Kubernetes. С их помощью можно указать, какие Pod’ы могут отправлять или получать трафик, как они могут взаимодействовать с внешними ресурсами и между собой внутри кластера.

По умолчанию в Kubernetes все Pod’ы могут свободно взаимодействовать друг с другом, что может представлять угрозу безопасности, особенно в случае крупных кластеров с множеством микросервисов. Network Policies позволяют ограничить этот трафик и обеспечить дополнительную изоляцию.

Основные компоненты Network Policies

1. Pod Selector. Этот элемент определяет, к каким Pod’ам будут применяться правила политики. Обычно используются метки (labels) для идентификации целевых Pod’ов.

2. Ingress Rules. Правила входящего трафика. Они определяют, какой трафик разрешен для входа в Pod’ы, покрытые политикой. Например, можно разрешить трафик только от определенных Pod’ов или с внешних IP-адресов.

3. Egress Rules. Правила исходящего трафика. Они определяют, куда Pod’ы могут отправлять трафик. Например, можно ограничить доступ только к определенным внешним сервисам или IP-адресам.

4. Namespace Selector. Определяет, из каких namespaces могут поступать или отправляться данные. Это полезно для разделения сетевого взаимодействия между Pod’ами в разных namespaces.

5. Policy Types. Тип политики указывает, касается ли она только входящего трафика (Ingress), только исходящего (Egress) или обоих.

Пример Network Policy

Рассмотрим простой пример Network Policy, который ограничивает входящий трафик к Pod’ам с меткой app: backend и разрешает его только от Pod’ов с меткой app: frontend.

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata:   name: allow-frontend-to-backend   namespace: default spec:   podSelector:     matchLabels:       app: backend   policyTypes:   - Ingress   ingress:   - from:     - podSelector:         matchLabels:           app: frontend

Разбор примера

1. podSelector: мы указываем, что данная политика применима к Pod’ам с меткой app: backend.

2. policyTypes: политика касается только входящего трафика (Ingress).

3. ingress: здесь определено правило, которое разрешает входящий трафик только от Pod’ов с меткой app: frontend.

Таким образом, с помощью этой политики мы запрещаем всем остальным Pod’ам и внешним источникам взаимодействовать с нашими backend-Pod’ами, кроме тех, которые имеют метку app: frontend.

Политики для исходящего трафика (Egress)

Также можно задать политику для исходящего трафика. Например, ограничим доступ Pod’ов только к определенному внешнему сервису по IP-адресу.

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata:   name: backend-egress-policy   namespace: default spec:   podSelector:     matchLabels:       app: backend   policyTypes:   - Egress   egress:   - to:     - ipBlock:         cidr: 192.168.1.0/24   - ports:     - protocol: TCP       port: 80

Разбор примера

1. egress: определено, что Pod’ы с меткой app: backend могут отправлять трафик только в подсеть 192.168.1.0/24 по TCP-порту 80.

2. policyTypes: политика относится к исходящему трафику (Egress).

Эта политика ограничивает возможность backend-Pod’ов выходить в сеть и взаимодействовать с внешними сервисами, находящимися за пределами указанной подсети.

Полезные сценарии использования Network Policies

1. Изоляция сервисов. Например, можно изолировать базы данных, чтобы они были доступны только определенным сервисам, и запретить прямой доступ от других Pod’ов.

2. Ограничение внешнего доступа. Можно ограничить доступ к вашему приложению из внешнего мира, открыв его только для определенных источников или IP-адресов.

3. Сегментация трафика. Можно сегментировать сетевой трафик внутри одного namespace или между несколькими namespaces, обеспечивая дополнительную безопасность для микросервисов.

4. Контроль исходящего трафика. Например, можно контролировать, к каким внешним сервисам Pod’ы могут подключаться, и предотвратить отправку данных на нежелательные или потенциально опасные внешние ресурсы.

Особенности и ограничения

• Network Plugin. Network Policies работают только с сетевыми плагинами, которые поддерживают эту функциональность, такими как Calico, Cilium или Weave Net. Это стоит учитывать при выборе сетевого решения для вашего кластера.

• Полная блокировка. Если на Pod’ы не применена никакая политика, они могут взаимодействовать с другими Pod’ами свободно. Но как только создается хотя бы одна политика, весь трафик, не соответствующий правилам, блокируется.

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

Заключение

Network Policies — это важный инструмент для обеспечения безопасности и управления трафиком в кластере Kubernetes. Использование этих политик позволяет бэкенд-разработчикам обеспечить изоляцию сервисов, контролировать доступ к данным и повысить общую защищенность системы. Внедрение правил сетевого взаимодействия особенно критично в микросервисных архитектурах, где большое количество Pod’ов и сервисов могут взаимодействовать друг с другом.

Рекомендуется использовать Network Policies с самого начала проектирования приложения, так как их отсутствие может привести к непредсказуемым последствиям, связанным с безопасностью.

вАЙТИ — DIY-медиа для ИТ-специалистов. Делитесь личными историями про решение самых разных ИТ-задач и получайте вознаграждение.

Что еще почитать

#Разработка

Как выстроить работу с заинтересованными лицами ИТ-проекта
В чем помогут предресерч, умение слушать и слышать, а также три главных вопроса к концепции ИТ-решения

Лучший алгоритм сортировки, или задачка с подвохом
Разбираю задание из интервью и рассказываю, каким будет правильное решение

Как мы приучили разработчиков читать ТЗ?
В статье рассказываю, как мы помогли джунам и сеньорам следовать ТЗ, работая над ним всей командой

#Железо

МикроЦОДы: виды, особенности и советы по внедрению
Сделали подробный обзор рынка микроЦОДов

HIL Simulation: как симулировать стрельбу гвоздями в условиях самоизоляции
Мы с командой протестировали ПО для строительного инструмента с помощью аппаратной симуляции.

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