Netcraze, Linux и k3s: архитектура корпоративной инфраструктуры

Небольшой компании часто не нужен большой дата-центр, но ей всё равно нужны границы доверия, управляемый доступ и восстановление после отказа. Практичная схема может состоять из Netcraze на периметре, управляемого коммутатора, отдельных VLAN, нескольких Linux-узлов k3s и внешнего резервного хранилища. Главная задача — не установить больше компонентов, а сделать понятными потоки трафика и ответственность каждого слоя.

В этом проекте Netcraze маршрутизирует офисные сегменты и поднимает VPN, Linux защищает сами серверы, а k3s управляет приложениями. Ни один слой не считается единственной защитой. Пример рассчитан на обучение и небольшой офис; требования по сертификации, аппаратному резервированию и доступности требуют отдельного проектирования.

Схема сети

Используем следующий адресный план:

• VLAN 10 Users: 10.20.10.0/24 — рабочие станции;
• VLAN 20 Servers: 10.20.20.0/24 — ingress и внутренние сервисы;
• VLAN 30 Management: 10.20.30.0/24 — SSH, API k3s и управление сетью;
• VLAN 40 IoT: 10.20.40.0/24 — камеры, панели и телефония;
• VLAN 50 Guest: 10.20.50.0/24 — только интернет;
• Pod CIDR: 10.42.0.0/16;
• Service CIDR: 10.43.0.0/16.

Диапазоны Pod и Service не должны пересекаться с офисами, филиалами, VPN и облачными VPC. Их выбирают до запуска кластера. Номера и адреса документируйте в IPAM или хотя бы в контролируемой таблице с владельцами и назначением.

Роль Netcraze на периметре

Маршрутизатор завершает подключение провайдера, обслуживает VLAN-интерфейсы, раздаёт DHCP клиентским сегментам и фильтрует обмен. Гостевой и IoT-сегменты по умолчанию не должны обращаться к Users, Servers и Management. Пользователям разрешаются только нужные приложения, DNS, печать и интернет. Доступ к управлению маршрутизатором открывается только из Management.

Не переносите все внутренние сервисы на сам роутер. Его задача — сеть и контролируемая точка входа. DNS с внутренними зонами, сбор журналов, мониторинг и резервные задания лучше размещать на выделенных Linux-системах или в управляемых сервисах.

Где размещать узлы k3s

Сетевые интерфейсы Linux-узлов располагаются в Servers или в отдельном cluster VLAN. Административный доступ разрешён из Management. Kubernetes API на TCP 6443 принимает подключения только от узлов и администраторской подсети. Flannel VXLAN на UDP 8472, kubelet 10250 и etcd 2379–2380 ограничиваются адресами узлов согласно выбранной топологии.

Для учебной среды достаточно одного server и одного agent. Для production с embedded etcd нужны минимум три server-узла, быстрые SSD и нечётное количество членов для кворума. Три виртуальные машины на одном физическом сервере не защищают от отказа этого сервера, электропитания или накопителя.

Фиксированный адрес API

Agent-узлам и администраторам нужен стабильный endpoint, например k3s-api.corp.example:6443. В односерверной схеме он может указывать на server. В HA перед несколькими server размещают load balancer или виртуальный IP. Имя и адрес добавляют в tls-san всех server-узлов, а критичные сетевые параметры делают одинаковыми.

Не публикуйте API через обычный port forwarding из интернета. Удалённый администратор сначала подключается по WireGuard к Netcraze, получает адрес из отдельного VPN-пула и только затем обращается к API. Firewall разрешает этот поток конкретной группе, а не любому VPN-клиенту.

Как публиковать приложения

Внутреннее приложение удобно публиковать через ingress-контроллер и корпоративное DNS-имя, например crm.corp.example. Пользователь обращается к одному адресу в Servers, ingress выбирает Service, а Kubernetes направляет запрос Pod. Базы данных при этом остаются ClusterIP или доступны только из разрешённых namespace.

Для внешнего сайта создайте отдельную границу: публичный reverse proxy, WAF или ingress-адрес в DMZ, затем разрешите только необходимый поток к приложению. Не направляйте WAN-порт прямо на случайный NodePort каждого узла. Публикация должна иметь владельца, TLS, обновления, журналирование и план отключения.

Встроенный ServiceLB k3s и внешний балансировщик решают разные задачи. Для HA API нужен стабильный адрес server-узлов; для Service типа LoadBalancer — контроллер, который выдаёт адрес приложения. Выбор зависит от L2/L3-сети и не должен делаться только ради привычного YAML.

DNS и сертификаты

Внутренний DNS хранит записи для API, ingress и инфраструктуры. DHCP выдаёт клиентам адрес этого резолвера. Для публичного сайта внешняя зона указывает на публичный адрес, а для внутреннего сервиса запись существует только внутри организации.

Автоматизация сертификатов должна учитывать challenge. HTTP-01 требует доступности HTTP извне, DNS-01 — API DNS-провайдера. Учётные данные DNS дают возможность изменять доменную зону, поэтому храните их в отдельном Secret с минимальными правами и ограничьте доступ RBAC и NetworkPolicy.

Матрица потоков

До настройки firewall зафиксируйте потоки:

• Users → ingress: TCP 443;
• Management → Linux: TCP 22;
• Management/VPN-admin → k3s API: TCP 6443;
• k3s nodes ↔ k3s nodes: только порты выбранного CNI, kubelet и datastore;
• workloads → DNS/NTP/внешние API: по списку;
• Guest → internet: без частных сетей;
• IoT → необходимые облачные адреса или локальный сервер: без свободного доступа к Users.

Граничный firewall контролирует VLAN и узлы, NetworkPolicy — Pod и namespace, RBAC — действия через Kubernetes API. Они дополняют друг друга: NetworkPolicy не закрывает SSH узла, а VLAN не ограничивает общение двух Pod внутри разрешённого сегмента.

Linux-hardening узлов

Узлы получают минимальную ОС, SSH по ключам, запрет root-входа и доступ только из Management. Отключайте ненужные службы, но не применяйте шаблон sysctl без проверки требований k3s и CNI. Включите синхронизацию времени, контроль целостности конфигурации, журналирование sudo и оповещения об окончании диска.

Обновления сначала проходят тестовый кластер. Версию k3s закрепляйте, проверяйте release notes и совместимость API. Одновременное обновление всех server-узлов лишает возможности быстро определить источник проблемы и увеличивает риск потери кворума.

Защита workloads

Для каждого приложения создавайте отдельный namespace и сервисный аккаунт. Вводите Pod Security, запускайте контейнеры без root, запрещайте privilege escalation и удаляйте capabilities. NetworkPolicy сначала запрещает обмен, затем разрешает только документированные связи. Образы закрепляются по версии или digest и проверяются на уязвимости.

Secrets шифруются в datastore параметром k3s, но доступ к ним ограничивается RBAC. Для особо чувствительных данных используйте внешний менеджер секретов и короткоживущие учётные данные. Никогда не храните реальные пароли в Git рядом с Deployment.

Резервирование по слоям

• Netcraze: защищённая копия конфигурации и запасное устройство или документированный план замены;
• Linux: конфигурация как код, список пакетов и автоматическое восстановление узла;
• k3s: snapshots datastore и server token;
• приложения: манифесты, PersistentVolume, дампы баз и ключи;
• DNS и PKI: зоны, инструкции перевыпуска и аварийные контакты.

Копии держите вне основной площадки и отдельно от учётных данных, которыми может завладеть злоумышленник. Тест восстановления должен включать не только появление Pod в статусе Running, но и проверку реальной операции приложения.

Мониторинг и реагирование

Собирайте состояние WAN и VPN, загрузку маршрутизатора, потерю пакетов, заполнение дисков, Node Ready, перезапуски Pod, срок сертификатов и ошибки резервного копирования. Журналы аутентификации Linux и Kubernetes audit log отправляйте на отдельную систему.

Для каждого сигнала нужен порог и действие. «Node NotReady более пяти минут» должно приводить к проверке сети, kubelet, диска и CNI. «Новый ClusterRoleBinding» — к сверке инициатора и заявки. Без процедуры оповещение становится фоновым шумом.

Порядок запуска проекта

1. Инвентаризация требований, сервисов и критичности.
2. Адресный план, VLAN и матрица доступа.
3. Тестовый сегмент Netcraze и управляемого коммутатора.
4. Подготовка Linux-шаблона и одного учебного k3s-кластера.
5. VPN для администрирования и закрытие API от WAN.
6. Ingress, DNS и тестовое приложение без бизнес-данных.
7. RBAC, Pod Security, NetworkPolicy и журналирование.
8. Резервное копирование с практическим восстановлением.
9. Перенос первого некритичного сервиса и сбор метрик.

Документация и продолжение

• Netcraze: сегменты;
• Netcraze: межсетевой экран;
• архитектура k3s;
• сетевые требования k3s;
• балансировщик для HA control plane;
• hardening k3s.

Статья может содержать партнёрские ссылки. Это не влияет на стоимость для вас, но помогает развивать блог.