Сегментация в облачных кластерах Kubernetes: изоляция команд и сервисов, сетевые политики и контроль доступа

Сегментация сети – один из фундаментальных механизмов обеспечения безопасности информационных систем. В классических инфраструктурах, построенных на физических серверах или виртуальных машинах, для этих целей традиционно используются 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

```

И теперь сетевая подсистема не пропускает пакеты, несмотря на разрешающее правило в политике.

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

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