Air-gapped Kubernetes для класифікованих навантажень: RKE2, Rancher та реальність офлайн-реєстру

1. Реальність air-gapped K8s

«Air-gapped» рідко означає те, на що натякають маркетингові презентації. У класифікованому розгортанні air gap — це акредитований кордон: жодного маршрутизованого шляху до публічного інтернету, жодного DNS-розпізнавання назовні, жодного неявного egress для менеджерів пакетів чи runtime-ів контейнерів. Кожен артефакт, що перетинає кордон, журналюється, сканується та схвалюється. Кластер поводиться так, ніби інтернету не існує — бо для органу акредитації його не існує.

Перша реальність, яку інженери недооцінюють, — Kubernetes припускає підключення. kubelet тягне з registry.k8s.io. Helm-чарти посилаються на quay.io та docker.io. Плагіни CNI завантажують бінарники під час встановлення. CSI-драйвери завантажують sidecar-образи. Оператори реконсилюються через підтягування нових digest-ів образів. Звичайний kubeadm init на відключеному хості провалюється на першій хвилині.

Друга реальність — проблема постійних оновлень. Кластер не розгортається один раз і не стоїть на місці. Мінорні релізи Kubernetes виходять кожні чотири місяці. CVE в containerd, runc, CoreDNS та ядрі з'являються щотижня. Рецензенти акредитації запитують одне понад усе інше: покажіть мені вашу каденцію патчингу та слід доказів. Air-gapped кластер без документованого, повторюваного конвеєра оновлень — це кластер, якому буде відмовлено в authority to operate на наступному перегляді.

Усе, що йде далі, — наслідок цих двох фактів: ніщо не тягне саме себе, і кластер повинен бути патчуваним роками.

2. Вибір дистрибутиву — RKE2 проти K3s проти kubeadm проти OpenShift

RKE2 (Rancher Kubernetes Engine 2). Загартований дистрибутив SUSE/Rancher. RKE2 1.31 постачається з профілем CIS-1.9 «з коробки»: kube-apiserver сконфігуровано з політикою аудиту, контролерами допуску та позою TLS, які вимагає бенчмарк CIS. Tarball релізу пакує кожен системний образ — kube-apiserver, kube-controller-manager, etcd, CoreDNS, CNI (Cilium або Canal), ingress-контролер — в один rke2-images-all.linux-amd64.tar.zst. Для air-gap це правильна відповідь у 80% випадків.

K3s. Легка сестра. Один бінарник, вбудований etcd або sqlite, ~50 МБ. Чудово підходить для edge-вузлів усередині анклаву (передові командні пункти, мобільні укриття, сенсорні шлюзи), де кластер працює на одному захищеному пристрої. K3s 1.31 має той самий шаблон air-gap tarball, що й RKE2, але з меншим набором компонентів і без преднастройки загартованого профілю — політику допуску ви приносите свою.

kubeadm. Upstream Kubernetes. Максимум гнучкості, максимум роботи. Кожен образ компонента треба дзеркалити вручну, кожен CNI встановлюється вручну, кожен контроль CIS застосовуєте ви. Вибирайте kubeadm лише тоді, коли орган акредитації забороняє розповсюджені вендором бінарники (рідко, але реально в деяких національних програмах).

OpenShift. Дистрибутив Red Hat. Сильніший інструментарій air-gap (oc mirror, Operator Lifecycle Manager з офлайн-каталогами) і серйозний акредитаційний слід (FIPS 140-3, CC EAL4+ на RHEL). Компроміс — ліцензування: місця OpenShift дорогі, і слід платформи важкий. Для програм, які вже мають корпоративні угоди з Red Hat, це шлях найменшого опору.

Для більшості оборонних проєктів ми рекомендуємо RKE2 1.31 з Rancher 2.10 як площиною керування мультикластерами, що сидить усередині класифікованого анклаву. K3s 1.31 заповнює edge-слот. Kubeadm та OpenShift — це програмно-специфічні рішення, керовані закупівлею та акредитацією, а не інженерними уподобаннями.

3. Офлайн-реєстр образів

Реєстр — це серце air-gapped платформи Kubernetes. Кожен под тягне з нього. Якщо він падає, кластер замерзає на наступному пулі образу. Якщо його скомпрометовано, скомпрометовано кожне навантаження.

Harbor 2.11. Реєстр enterprise-класу, випускник CNCF. Нативна інтеграція з Trivy сканує кожен запушений образ на CVE проти офлайн-бази вразливостей, яку ви синхронізуєте тим самим затвердженим процесом передачі, що й образи застосунків. Harbor підтримує перевірку підписів cosign на pull, RBAC у межах проєкту, політики реплікації та модель robot-аккаунтів, що чисто працює з webhook-ами допуску. Для первинного реєстру всередині анклаву Harbor — це за замовчуванням.

zot. Нативний OCI single-binary реєстр на Go. Набагато легший за Harbor (без Postgres, Redis чи Trivy sidecar). zot 2.1 підтримує OCI 1.1 referrers, cosign і має малий слід, що пасує передовим вузлам, де Harbor був би надмірним. Зв'яжіть zot на краю з Harbor у центральному сайті, реплікуючи в одну сторону.

Sonatype Nexus. Поліглотний менеджер артефактів. Якщо програма вже стандартизувалася на Nexus для Maven, npm та APT-дзеркал, додавання Docker-репозиторіїв тримає все в одному інструменті й одному наборі журналів аудиту. Сканування контейнерів у Nexus слабше за Harbor, тому воно поєднується з окремим шлюзом сканування у конвеєрі прийому.

Шаблон, до якого сходиться більшість великих програм, — це реєстр реєстрів: один центральний Harbor усередині анклаву як джерело істини, один zot на сайт або edge-кластер та документована топологія реплікації. Прикладні кластери ніколи не тягнуть з центрального Harbor безпосередньо — вони тягнуть з локального дзеркала zot. Домени відмов залишаються малими. Мережеві round-trip-и — короткими. Акредитаційна діаграма залишається такою, що поміщається на одній сторінці.

4. Sneakernet та односторонні діоди

Образи, Helm-чарти, бази вразливостей, дзеркала пакетів ОС, GitOps-репозиторії — усе має фізично перетинати кордон. Домінують два транспортні шаблони.

Sneakernet. Затверджені знімні носії, які переносять руками. Носій очищують, записують, перевіряють хеш, опечатують, підписують перетин кордону, перевіряють хеш на високій стороні, поглинають у staging-реєстр, сканують, ручно схвалюють, потім просувають до продакшн-реєстру. Повний цикл займає від годин до днів. Це повільно, аудитоване й виживає в будь-якому перегляді акредитації.

Односторонні дата-діоди. Апаратно забезпечена односпрямована передача (Owl Cyber Defense, Fox-IT DataDiode, Advenica). Пропускна здатність реальна (1–10 Гбіт/с на сучасному обладнанні), а відсутність зворотного шляху забезпечується в оптоволокні, а не в конфігурації. Діоди чудово працюють для телеметрії, що виходить з високої сторони; для образів, що входять, відсутність підтвердження ускладнює повторні спроби, тому більшість програм поєднують діод зі строгим протоколом resend-on-checksum-failure поверх.

Обидва шаблони мають той самий workflow поетапного прийому: отримання → карантинний реєстр → автоматичне сканування (Trivy, ClamAV, YARA) → content disarm and reconstruction для будь-якого не-контейнерного артефакту → ручне схвалення аналітика → просування до продакшн-реєстру. Пропуск етапу карантину — найпоширеніша причина зауважень акредитації.

5. GitOps в air gap

GitOps працює всередині анклаву — за умови, що кожне посилання внутрішнє. ArgoCD 2.13 і Flux 2.4 обидва щасливо працюють air-gapped. Цикл реконсиляції не хвилює, що сервер Git — це Gitea чи GitLab, розгорнутий на високій стороні, а не github.com. Ламається кожен Helm-чарт, що посилається на зовнішній репозиторій чартів, кожен Kustomize-оверлей, що тягне base з публічного Git-remote, і кожен оператор, що спостерігає за зовнішнім потоком образів.

Шаблон manifest mirror це виправляє. Запланована задача на низькій стороні тягне upstream Helm-чарти, образи контейнерів та Git-репозиторії; переписує кожне зовнішнє посилання (repository: docker.io/bitnami/postgresql стає repository: harbor.enclave.mil/bitnami/postgresql); комітить у внутрішнє Git-дзеркало; та експортує пакет для sneakernet. Усередині анклаву ArgoCD вказує виключно на дзеркало. Немає резервного шляху до інтернету, бо немає інтернету.

Виявлення дрейфу без phone-home є простим — ArgoCD обчислює diff-и проти стану в кластері, а не проти зовнішнього сервісу. Єдина функція, яку ви втрачаєте, — автоматичне upstream-сповіщення про нові версії чартів; це виявлення переміщується в задачу дзеркала на низькій стороні, де воно й мало бути. Для ширшого шаблону див. наш огляд про DevSecOps та zero trust в оборонному конвеєрі.

6. Цілісність ланцюга постачання

Air gap зупиняє вихідну ексфільтрацію; він не зупиняє шкідливий образ, що прибув через затверджений канал. Цілісність ланцюга постачання — друга лінія оборони.

Підписування cosign. Кожен образ, просунутий до продакшн-реєстру, підписується ключем cosign, чий root знаходиться в HSM анклаву. Підписування відбувається на кроці просування, після сканування та схвалення аналітиком. Підпис засвідчує «цей образ перевірено через наш процес», а не «цей образ автентичний upstream» — upstream-походження перевіряється окремо на шлюзі прийому низької сторони.

Kyverno або OPA Gatekeeper на admission. ClusterPolicy відхиляє будь-який под, чий образ не підписано ключем у trust bundle анклаву й чий digest не зафіксовано. Посилання на основі тегів (:latest, :v1) повністю блокуються — лише digest-и @sha256:... проходять admission. Kyverno 1.13 — легший варіант; Gatekeeper пасує програмам, що вже інвестували в Rego.

Перевірка SBOM. Кожен підписаний образ несе приєднаний SBOM SPDX або CycloneDX як OCI referrer. Політика admission перевіряє підпис SBOM і опційно перевіряє наявність заборонених компонентів (напр., log4j 2.x нижче 2.17, будь-який пакет зі списку заборонених програми). Для ширшої картини див. примусове застосування SBOM в оборонних конвеєрах.

7. Day-2 операції

Каденція патчингу CVE — це там, де більшість air-gapped програм програють розмову про акредитацію. Питання рецензента просте: критичний CVE розкрили вчора — коли він з'явиться у вашому продакшн-кластері й де докази?

Захисна відповідь має три рівні. Hot-fix для критичних CVE з активною експлуатацією: конвеєр прийому низької сторони приймає аварійний патч протягом 24 годин, sneakernet працює поза циклом, продакшн-реєстр отримує патчований образ протягом 72 годин, а аварійні зміни покриваються записами change management. Запланована вікно для high та medium CVE: щомісячні вікна обслуговування протягують куровану партію через повний конвеєр поетапного прийому. Квартальні мінорні оновлення для самої control plane Kubernetes: патч-релізи RKE2 спочатку приземляються в тестовий кластер, потім у продакшн, із документованим планом відкату.

План життєвого циклу кластера, що задовольняє рецензентів акредитації, — це не однієсторінкова діаграма. Це письмовий runbook, що охоплює: процедуру оновлення control plane, процедуру оновлення воркерів, навчання резервного копіювання та відновлення etcd (виконане щокварталу, не теоретичне), процедуру оновлення CNI, процедуру відмови реплікації реєстру та поіменно зазначених осіб, відповідальних за кожен пункт. Рецензенти це читають. Вони помічають, коли runbook посилається на інструмент, який команда насправді не використовує.

Для ширшого контексту хмарної архітектури, в якій живуть ці кластери, див. суверенну хмарну архітектуру для оборони.

8. Федерація між анклавами

Оборонна організація рідко керує одним кластером. Є неклассифікований анклав, анклав NATO SECRET, національний SECRET анклав, інколи TOP SECRET анклав для конкретних програм. Інстинкт — «федерувати» їх через Kubernetes Federation v2 або подібний механізм. Інстинкт неправильний.

Федерація через кордони класифікації заборонена будь-якою акредитаційною рамкою, з якою ми працювали. Правильний шаблон — це окремі кластери на кожен рівень класифікації, з'єднані лише через крос-доменні шлюзи. Кожен кластер має свою control plane, свій реєстр, свій GitOps-репозиторій, свої ключі підписування. Маніфести для спільних навантажень дублюються — так, дублюються, з усім ризиком розходження версій, що з цього випливає — бо альтернатива — це федерована control plane, що порушує кордон.

Стратегія дублювання GitOps — це операційна дисципліна, що робить це керованим. Те саме дзеркало низької сторони, що виробляє неклассифікований пакет, виробляє пакет NATO SECRET і національний пакет SECRET, кожен з тим самим upstream-вмістом, але різними ключами підписування й різними цільовими реєстрами. Git-репозиторії розходяться лише на специфічній для анклаву конфігурації (хости реєстрів, мережеві політики, посилання на секрети). Дрейф між анклавами виявляє інструмент порівняння на низькій стороні, що читає маніфести публічної сторони й редаговані версії маніфестів високої сторони, що повертаються через діод.

Потік крос-доменних повідомлень — телеметрія вгору, команди вниз, розвіддані вбік — проходить через акредитовані крос-доменні рішення (Forcepoint Trusted Gateway, Owl, національні еквіваленти), а не через інтеграцію на рівні Kubernetes. Кластер не знає, що він мультианклавний. Кожен кластер вірить, що він сам, і саме ця властивість дозволяє його акредитувати. Для мережевої моделі, що огортає ці анклави, див. zero trust у військових мережах.