Сегментация сети – один из фундаментальных механизмов обеспечения безопасности информационных систем. В классических инфраструктурах, построенных на физических серверах или виртуальных машинах, для этих целей традиционно используются VLAN и межсетевые экраны. Однако с распространением контейнеров и систем оркестрации подходы к сетевой изоляции претерпели изменения. В среде Kubernetes невозможно напрямую применять VLAN или традиционные межсетевые экраны для управления трафиком между компонентами. Несмотря на это, потребность в сегментации сохраняется, и на смену классическим решениям пришли новые, адаптированные под динамическую инфраструктуру контейнеров. В этой статье мы рассмотрим такой инструмент и его расширенные возможности в составе платформы «Боцман».
В стандартном API Kubernetes предусмотрен встроенный ресурс для ограничения сетевого трафика — NetworkPolicy. Поскольку Kubernetes не выполняет сетевые функции самостоятельно, а лишь предоставляет соответствующий интерфейс, обработка сетевых политик делегируется компоненту, реализующему спецификацию CNI.
На сегодняшний день существует три наиболее популярных решения, обеспечивающих работу сети в Kubernetes: Flannel, Calico и Cilium. В платформе «Боцман» в мы выбрали Cilium.
В современных корпоративных ИТ-ландшафтах бизнес-сервисы всё чаще строятся на основе распределённых (микросервисных и близких к ним) архитектур. При таком подходе разработку одного сервиса может вести несколько команд, иногда достаточно больших. В результате возникает потребность в чётком разграничении их доступа в рамках общей инфраструктуры.
Для этого в «Боцмане» есть технология проектов, позволяющих объединять несколько неймспейсов. На уровне этих проектов обеспечиваются централизованное управление доступом (RBAC) и квотирование ресурсов.
Если проанализировать обратную связь от пользователей, можно увидеть устойчивый спрос на возможность управлять не только доступом и ресурсами, но и сетевым трафиком в границах проекта. И у нас есть готовое решение, которое удовлетворяет эту потребность.
Принятие решения о прохождении трафика основывается на достаточно понятном алгоритме:

Если существует любое запрещающее (deny) правило, под которое попал пакет, трафик будет отклонен.
Если нет запрещающих правил, система ищет разрешающие правила, и если они есть, пропускает трафик.
Если для выбранного трафика нет никаких правил, платформа проверяет глобальную политику (policy-enforcement). Если находит значения never или default, пропускает трафик, а в случае always блокирует.

Такая схема не просто делает поведение сетевых политик предсказуемым, но и позволяет гибко настраивать как точечные разрешения и запреты, так и общий уровень изоляции по умолчанию.
Рассмотрим случай, когда глобальная политика выставлена в always и в кластере запрещен любой явно неразрешенный трафик. В таком кластере мы создали 2 проекта.
В пространстве имен server находится просто http сервер, который мы будем использовать для проверки связанности. Так как политика выставлена в always, весь трафик блокируется:
```

echo-busybox # nc -vzw 1 echo.server 5678

nc: echo.server (172.16.245.175:5678): Operation timed out

non-echo-busybox # nc -vzw 1 echo.server 5678

nc: echo.server (172.16.245.175:5678): Operation timed out

```
Далее разрешаем общение сервисов внутри проекта, при этом создаются специальные политики. Вот пример для объекта echo:
```yaml

apiVersion: cilium.io/v2

kind: CiliumClusterwideNetworkPolicy

metadata:

name: echo-project-allow-all

spec:

egress:

- toEndpoints:

- matchLabels:

k8s:io.cilium.k8s.namespace.labels.field.cattle.io/projectId: p-4p5pl

endpointSelector:

matchLabels:

k8s:io.cilium.k8s.namespace.labels.field.cattle.io/projectId: p-4p5pl

ingress:

- fromEndpoints:

- matchLabels:

k8s:io.cilium.k8s.namespace.labels.field.cattle.io/projectId: p-4p5pl

```
Здесь задействуются механизмы Cilium, с которыми можно использовать расширенные метаданные эндпоинтов для фильтрации трафика. Внутренняя карта `k8s:io.cilium.k8s.namespace.labels` содержит все лейблы пространства имен.
Проверяем:
```

echo-busybox # nc -vzw 1 echo.server 5678

echo.server (172.16.245.175:5678) open

non-echo-busybox # nc -vzw 1 echo.server 5678

nc: echo.server (172.16.245.175:5678): Operation timed out

```
Дальнейшая фильтрация внутри проекта возможна с помощью мандатного разграничения доступа. Задаем уровень конфиденциальности так же, как и в ОС Astra Linux Special Edition, и фильтрация будет происходить на их основе.
Попробуем задать серверу 3-й уровень конфиденциальности, а клиенту – 4-й.
```

echo-busybox # nc -vzw 1 echo.server 5678

nc: echo.server (172.16.245.175:5678): Operation timed out

```
И теперь сетевая подсистема не пропускает пакеты, несмотря на разрешающее правило в политике.
Подведем итоги. Проекты «Боцмана» хорошо интегрируются с сетевыми политиками и позволяют использовать механизмы сегментации трафика совместно с проектами. Применение сетевых политик вместе с мандатным разграничением доступа еще сильнее повышает уровень безопасности внутри кластера.

Статью подготовил Масленников Федор, заместитель технического директора команды разработки платформы «Боцман» (входит в «Группу Астра»).