Kubernetes між анклавами безпеки: багаторівневі кластери

Оборонні програми рідко працюють на одному рівні секретності. Те саме місійне програмне забезпечення, яке приймає відкриті дані в анклаві Unclassified, часто має варіант Secret, що поєднує їх із чутливим збором, а іноді й варіант Top Secret поверх цього. Інстинкт інженера, звиклого до комерційного Kubernetes, — моделювати ці рівні як простори імен, орендарів чи віртуальні кластери в межах однієї платформи. Цей інстинкт хибний для секретної роботи, а виправлення помилки коштує дорого. У багаторівневому захищеному (MLS) середовищі кластер Kubernetes — і мережа, на якій він розміщений — є межею секретності, а не деталлю розмежування орендарів усередині. Ця стаття розповідає, як запускати Kubernetes між анклавами безпеки: один акредитований кластер на рівень секретності, сувора ізоляція політик усередині кожного, верифіковане походження образів і контрольоване, одностороннє переміщення артефактів між доменами.

Межа — це кластер, а не простір імен

Kubernetes надає кілька механізмів, що виглядають як ізоляція: простори імен, NetworkPolicies, RBAC, квоти ресурсів і контроль допуску. Кожен із них — засіб розмежування орендарів, що діє всередині єдиної межі довіри. Усі вони спільно використовують той самий сервер API, те саме сховище etcd, те саме ядро Linux на кожному вузлі та те саме середовище виконання контейнерів. Вихід із контейнера через вразливість ядра, недолік у шляху авторизації сервера API чи один надто широкий ClusterRoleBinding можуть перетнути всі ці м’які межі одразу.

Акредитатор, який розглядає систему MLS, ставить просте запитання: що фізично чи криптографічно завадить даним Secret потрапити на сторону Unclassified? «NetworkPolicy» — неприйнятна відповідь, бо NetworkPolicy забезпечується тим самим плагіном CNI та ядром, на яких працюють самі робочі навантаження. Прийнятна відповідь — відокремлення: окремі кластери, окремі мережі, окреме обладнання чи окремі криптографічно ізольовані розділи, кожен акредитований для обробки рівно одного рівня. Простори імен залишаються корисними — але лише як адміністративні відсіки в межах одного анклаву, ніколи як лінія між Unclassified і Secret.

Це той самий принцип, що лежить в основі рішень міждоменної взаємодії для оборони: дані переміщуються між рівнями лише через акредитований охоронець, ніколи через спільний програмний засіб керування, до якого можуть дотягнутися обидві сторони. Багатоанклавний Kubernetes просто застосовує цей принцип до рівня оркестрації.

Один кластер на анклав: еталонна топологія

Еталонна топологія для трирівневої програми — три повністю незалежні розгортання Kubernetes, по одному на анклав:

Анклав Unclassified / розробки. Тут відбувається більшість інженерної роботи. Він має найширшу зв’язність (часто шлях до інтернету через проксі для витягування вхідних залежностей), найбільш дозволений темп змін і конвеєр збирання, що виробляє артефакти, які вищі анклави згодом споживатимуть. Він усе ще захищений — мережа за принципом default-deny, підписані образи, без привілейованих подів — але це єдиний анклав, де народжуються нові образи.

Анклав Secret. Відключений від публічного інтернету, цей кластер запускає варіант Secret місійного програмного забезпечення. Він витягує образи лише з власного внутрішнього реєстру анклаву, який наповнюється виключно просуванням знизу. Його темп змін повільніший, і кожне розгортання прив’язане до акредитованого випуску. Операційна дисципліна тут нагадує розгортання Kubernetes з повітряним проміжком — офлайн-реєстри, без живих вхідних витягувань і процес оновлення, який має витримати акредитацію.

Анклав Top Secret. Найбільш обмежений кластер, у найбільш ізольованій мережі, з найсуворішими кадровими та фізичними контролями. Він отримує курований підмножину артефактів зі сторони Secret, знову ж таки лише через акредитоване передавання.

Кожен анклав — це повний, самодостатній всесвіт Kubernetes: власна площина керування та etcd, власні CNI та класи сховищ, власний реєстр образів, власний постачальник ідентичності та RBAC, власний контролер GitOps і власний стек спостережуваності. Ніщо у вищому анклаві не залежить від доступності сервісу нижчого анклаву під час виконання. Саме ця незалежність дозволяє акредитувати кожен кластер на власних умовах.

Чому федерація між рівнями — це прихований канал

Спокуслива абревіатура — федерувати ідентичність, розповсюдження образів чи GitOps між анклавами, щоб оператори мали одну консоль. Опирайтеся цьому. Жива федерація автентифікації, що видає токен, придатний для використання і на стороні Unclassified, і на стороні Secret, за визначенням є каналом реального часу між двома рівнями — саме тим, що відокремлення покликане запобігти. Наявність чи відсутність успішного входу, час оновлення токенів, навіть коди помилок можуть кодувати інформацію через межу. Та сама логіка виключає спільний реєстр, у який пишуть обидві сторони, або єдиний контролер GitOps, що узгоджує кластери на різних рівнях. Будь-що, що підтримує синхронне з’єднання через межу, є потенційним прихованим каналом і не пройде перевірку.

Ізоляція політик усередині кожного анклаву

Відокремлення між анклавами необхідне, але недостатнє. Усередині кожного кластера вам усе ще потрібне суворе розмежування, бо анклав розміщує багато робочих навантажень, сервісів і команд, які не повинні вільно дотягуватися одне до одного. Саме тут нативні засоби Kubernetes здобувають своє місце.

Почніть із контролю допуску. Механізм політик, такий як Kyverno чи OPA Gatekeeper, застосовує беззаперечні правила в момент допуску робочого навантаження: запускатися можуть лише підписані образи з власного реєстру анклаву; жоден под не може запитувати привілейований режим, мережу хоста чи монтування шляхів хоста; кожен контейнер працює як не-root користувач з файловою системою кореня лише для читання та зменшеним набором можливостей; і кожен простір імен відповідає обмеженому профілю Pod Security Standards. Це ті самі засоби посилення захисту, докладно розглянуті у статті посилення захисту Kubernetes для оборонних навантажень, застосовані ідентично в кожному анклаві, щоб базова лінія не дрейфувала між рівнями.

Мережа всередині анклаву працює за принципом default-deny. Кожен простір імен починається з NetworkPolicy, яка відкидає весь вхідний і вихідний трафік, а зв’язність надається явно для кожної пари сервісів. Трафік схід-захід між чутливими відсіками проходить через взаємний TLS, зазвичай через сервісну сітку, щоб доступ контролювала ідентичність робочого навантаження — а не лише його положення в мережі. Квоти ресурсів і діапазони обмежень не дають одному скомпрометованому чи некоректному навантаженню виснажувати кластер.

RBAC і дисципліна break-glass

RBAC усередині кожного анклаву дотримується найменших привілеїв без винятків. Щоденні оператори отримують ролі, обмежені простором імен; ніхто не має постійного cluster-admin. Можливість cluster-admin живе за процедурою break-glass: обліковий запис, що запечатаний, чиє використання спричиняє сповіщення, і чия кожна дія записується до незмінного сховища аудиту. Оскільки анклави незалежні, процедура break-glass також незалежна — її використання в анклаві Secret не дає нічого в анклаві Unclassified. Службові облікові записи прив’язані до одного простору імен, їхні токени короткочасні та прив’язані до конкретного навантаження, і жоден із них ніколи не використовується повторно між кластерами.

Походження образів: довіра, здобута при збиранні, перевірена при запуску

У багатоанклавній архітектурі ланцюг постачання — найпривабливіша поверхня атаки, бо образ, зібраний одного разу на низькій стороні, може зрештою запускатися на рівні Top Secret. Тому кожен образ повинен нести верифіковане походження, яке найвищий анклав може перевірити, не довіряючи жодному нижчому анклаву під час виконання.

Дисципліна така: збирайте у найнижчому анклаві, який може зібрати образ, генеруйте повний перелік компонентів програмного забезпечення (SBOM) у форматі SPDX або CycloneDX, скануйте його за базою даних вразливостей, віддзеркаленою в цей анклав, і підписуйте і образ, і SBOM ключем Sigstore Cosign. Підпис прив’язує дайджест образу до відомого процесу збирання. Кожен анклав має власний реєстр — Harbor і zot є поширеними варіантами для відключеної роботи — і контролер допуску кожного кластера перевіряє підпис Cosign за публічним ключем, специфічним для анклаву, перш ніж дозволити запуск образу. Непідписаний образ, або той, чий дайджест не відповідає просунутому запису, ніколи не запускається.

Це має значення через межу, бо кластер високої сторони не довіряє реєстру низької сторони; він довіряє криптографічному підпису та дайджесту, зафіксованому під час просування. Навіть якби реєстр низької сторони був скомпрометований після просування образу, висока сторона відхилила б будь-яку заміну, чий дайджест відрізняється від зафіксованого.

Контрольоване просування між доменами

Просування — єдиний санкціонований спосіб, яким артефакт перетинає межу анклаву, і воно суворо односторонньо з низького до високого. Шлях проходить через акредитоване рішення міждоменної взаємодії або, для найсуворіших з’єднань, апаратний діод даних, що фізично дозволяє передавання лише в одному напрямку.

Охоронець передавання виконує справжню роботу, а не лише копіювання. Він перевіряє дайджест образу та підпис Cosign за списком дозволених затверджених артефактів; він інспектує SBOM і відхиляє будь-який образ, що містить заборонений компонент, незатверджену ліцензію чи відомий вразливий пакет вище порогу програми; він видаляє чи нормалізує метадані, які могли б нести приховані дані; і він реєструє передавання з ідентичністю оператора, позначкою часу та дайджестом артефакту до запису аудиту з обох сторін. Лише після того, як кожна перевірка пройдена, артефакт записується до реєстру високої сторони, звідки високий кластер може його витягнути.

Переміщення з високого до низького — небезпечний напрямок, і до нього ставляться відповідно. Витягування журналів, метрик чи телеметрії збирання вниз з анклаву Secret до Unclassified — це потенційний витік, тож воно або прямо заборонене, або маршрутизується через окремий, значно суворіший перегляд із людським рішенням щодо кожного випущеного запису. Стандартна позиція полягає в тому, що дані течуть угору та залишаються нагорі.

GitOps і операції без перетину лінії

Кожен анклав має власний контролер GitOps — Argo CD чи Flux — що узгоджується з репозиторієм Git, який живе всередині цього анклаву. Маніфести бажаного стану для вищого анклаву самі є артефактами, що просуваються вгору через рішення міждоменної взаємодії, перевіряючись так само, як образи. Це зберігає слід аудиту (репозиторій високої сторони фіксує точно те, що було просунуто та ким) без жодного з’єднання контролера через межу.

Спостережуваність дотримується того самого правила. Falco для виявлення загроз під час виконання, журнал аудиту Kubernetes, метрики Prometheus і централізовані журнали контейнерів — усі працюють усередині кожного анклаву та подаються до локального SIEM анклаву. Телеметрія ніколи не транслюється з високого анклаву на панель низької сторони; якщо об’єднана, міжрівнева операційна картина справді потрібна, вона будується експортом перевірених зведень угору до найвищого анклаву, а не витягуванням сирої телеметрії вниз. Збереження аудиту встановлюється для кожного анклаву відповідно до його вимоги акредитації, а безперервний моніторинг — повторні скани вразливостей за внутрішнім дзеркалом анклаву, виявлення дрейфу, періодична повторна верифікація підписів образів — працює незалежно в кожному кластері.

Скільки це коштує і чому воно того варте

Запуск трьох незалежних кластерів замість одного багатоорендного — це справді більше роботи: три площини керування для оновлення, три реєстри для наповнення, три постачальники ідентичності, три конвеєри GitOps і процес просування між ними. Інженери відчувають тертя щоразу, коли образ, що працює на низькій стороні, доводиться просунути, перш ніж він зможе запуститися вище. Але це тертя і є властивістю безпеки, а не його дефектом. Шлюз просування — це місце, де перевіряється походження, виявляються заборонені компоненти та створюється повний, незмінний запис того, що перетнуло межу. Згортання анклавів в один кластер заради економії зусиль обміняло б акредитовану, захищувану архітектуру на одне спільне ядро та сервер API, що стоять між Unclassified і Secret — обмін, який не прийме жоден акредитатор і якого не повинна хотіти жодна програма.

Для команд, яким також доводиться тримати вищі анклави відключеними, операційні шаблони природно поєднуються з практикою Kubernetes з повітряним проміжком: офлайн-реєстри, віддзеркалені залежності та дисципліна оновлення, що не припускає живого шляху до зовнішнього світу.