Kubernetes для оборонних навантажень: оркестрування засекречених контейнеризованих застосунків

Оркестрування контейнерів стало домінуючим шаблоном розгортання для сучасного оборонного програмного забезпечення, проте оперативні вимоги безпеки засекречених середовищ накладають обмеження, яких стандартні конфігурації Kubernetes не враховують за замовчуванням. Стандартний кластер, розгорнутий за допомогою kubeadm, відкриває неавтентифіковані API kubelet, зберігає секрети у відкритому тексті в etcd, не застосовує мережевих політик між подами та генерує журнали аудиту, які не пересилаються і не захищені від фальсифікації. Кожен із цих параметрів за замовчуванням є знахідкою під час будь-якої серйозної перевірки безпеки. Ця стаття охоплює все необхідне для правильного запуску Kubernetes у засекреченому середовищі: від посилення вузлів за базовими рівнями CIS і STIG через керування секретами на основі HSM, мікросегментацію мережі, архітектуру журналів аудиту, засоби контролю ланцюжка постачання образів до документального шляху до Повноважень на експлуатацію.

Чому оркестрування контейнерів важливе для сучасного розгортання оборонного програмного забезпечення

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

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

Складність полягає в тому, що проєкт Kubernetes розроблено для комерційних хмарних середовищ, орієнтованих на Інтернет, і його конфігурація за замовчуванням відображає цю спадщину. Оборонні програми, що приймають Kubernetes, мають розглядати конфігурацію за замовчуванням як відправну точку для посилення, а не прийнятну базову лінію. Розрив між стандартним кластером і кластером, готовим до акредитації, є значним, але він добре задокументований DISA та Центром безпеки в Інтернеті, і його можна усунути цілеспрямованою конфігураційною роботою.

Посилення вузлів: відповідність CIS benchmark і STIG для робочих вузлів Kubernetes

Посилення вузлів починається на рівні операційної системи ще до встановлення будь-якого компонента Kubernetes. Робочі вузли мають будуватися на основі базового образу, посиленого за STIG або CIS рівень 2 — Red Hat Enterprise Linux CoreOS (RHCOS) для кластерів на основі OpenShift або посилений збірник Ubuntu чи Rocky Linux для upstream Kubernetes. Базова конфігурація ОС охоплює секціонування файлової системи (окремі монтування /tmp, /var, /var/log), посилення параметрів ядра (відключення IP-переадресації, крім випадків, коли CNI її вимагає, увімкнення syncookies, відключення IP source routing), обов'язковий контроль доступу (SELinux у режимі enforcing або профілі AppArmor) та видалення непотрібних пакетів і служб.

На рівні Kubernetes DISA STIG для Kubernetes і CIS Kubernetes Benchmark рівень 2 сходяться на базовому наборі вимог до конфігурації kubelet. Порт kubelet лише для читання має бути відключений (--read-only-port=0). Анонімна автентифікація має бути відключена (--anonymous-auth=false). Режим авторизації має бути встановлений на Webhook, що делегує всі рішення про авторизацію рушію RBAC сервера API, а не довіряє локальним рішенням вузла. Ротацію сертифікатів необхідно ввімкнути, щоб клієнтські сертифікати kubelet поновлювалися автоматично до закінчення строку дії. Середовище виконання контейнерів — containerd або CRI-O — має бути налаштоване з профілем seccomp за замовчуванням (RuntimeDefault), що застосовується до всіх подів, якщо вони явно не потребують більш дозвільного або спеціального профілю.

Запуск kube-bench, аудитора CIS benchmark з відкритим кодом, проти налаштованого кластера дає структурований звіт відповідності у форматі XCCDF. Цей звіт є обов'язковим додатком у більшості пакетів акредитації. Знахідки Категорії I (високого ступеня серйозності) необхідно усунути до подання; знахідки Категорії II слід усунути або задокументувати з компенсуючими засобами контролю. Автоматизовані плейбуки виправлення — Ansible або аналогічні, — що відтворювано застосовують засоби контролю benchmark до всіх вузлів, переважно над ручною конфігурацією, оскільки вони зменшують дрейф конфігурації та формують перевіряємі записи змін.

Застосування мережевих політик: мікросегментація між засекреченими навантаженнями

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

Базовий шаблон посилення — це політика default-deny-all, що застосовується до кожного простору імен під час початкового розгортання кластера. Ця політика забороняє весь вхідний та вихідний трафік, якщо явне дозвільне правило не дозволяє його. Потім явні дозвільні правила додаються для кожного необхідного шляху трафіку: DNS-резолюція (TCP і UDP порт 53 до CoreDNS у kube-system), трафік перевірки стану від kubelet до контейнерів застосунків та специфічні для застосунку з'єднання між службами. Кожне дозвільне правило має бути максимально звуженим — за селектором міток пода, селектором міток простору імен та портом — а не використовувати широкі діапазони CIDR, які пройдуть перевірку аудитора, але насправді не обмежать бокове переміщення.

Для навантажень, що працюють на різних рівнях секретності та мають співіснувати на спільній інфраструктурі, однієї лише мережевої політики на основі міток недостатньо. Плагін CNI застосовує політики на рівні netfilter ядра Linux, і достатньо привілейований скомпрометований контейнер може обійти netfilter. Оборонні програми, що розміщують навантаження різних рівнів чутливості в одному кластері, мають розміщувати кожен рівень чутливості в окремому пулі вузлів із виділеними мережевими інтерфейсами або VLAN і застосовувати засоби контролю міжрівневого трафіку на рівні апаратного або гіпервізорного забезпечення. Архітектура міжмережевого підключення оборонної хмари забезпечує фізичне та логічне розділення, яке засоби контролю лише на основі політик не можуть гарантувати на спільній ядерній інфраструктурі.

Керування секретами: інтеграція Kubernetes із сховищами ключів на основі HSM

Секрети Kubernetes за замовчуванням зберігаються в etcd як значення у форматі base64 без жодного шифрування. Будь-який користувач або процес із доступом для читання до etcd — або з достатніми дозволами RBAC для виклику kubectl get secret — може отримати значення у відкритому тексті. Для засекречених середовищ це не прогалина в конфігурації; це фундаментальна архітектурна проблема, яку необхідно вирішити до збереження будь-яких чутливих даних у кластері. Рішення — шифрування etcd у стані спокою за допомогою провайдера KMS, що делегує керування ключами до сховища ключів на основі HSM.

Ресурс EncryptionConfiguration kube-apiserver задає список провайдерів шифрування для кожного типу ресурсів. Для провайдера kms конфігурація вказує на Unix-сокет, де прослуховується процес плагіна KMS. Плагін транслює gRPC-протокол Kubernetes KMS у виклики до HSM або сервісу керування ключами — зазвичай через PKCS#11 для мережевого HSM або через API керування ключами хмарної системи KMS оборонного класу. Коли сервер API записує секрет до etcd, він викликає плагін KMS для шифрування ключа шифрування даних (DEK) під ключем шифрування ключів (KEK), що зберігається в HSM. В etcd поряд із зашифрованим текстом зберігається лише обгорнутий DEK. Для розшифрування необхідний зворотний зв'язок з HSM. HSM повинен мати сертифікацію FIPS 140-2 рівня 3 для навантажень рівня SECRET; рівень 2 зазвичай прийнятний лише для матеріалів SENSITIVE BUT UNCLASSIFIED.

Журналювання аудиту: фіксація подій сервера API для відповідності вимогам і криміналістики

Сервер API Kubernetes генерує журнал аудиту кожного запиту, що він обробляє: хто подав запит, яке дієслово та ресурс були задіяні, який простір імен, чи запит успішний, та — залежно від налаштованого рівня аудиту — повний запит і тіло відповіді. Цей журнал є авторитетним записом для відповіді на питання «хто і що робив у цьому кластері та коли». Для засекречених середовищ комплексне журналювання аудиту не є необов'язковим; це конкретна вимога засобу контролю в RMF, JSIG та аналогічних системах, а відсутність адекватних журналів аудиту зазвичай є критичною знахідкою під час акредитаційної перевірки.

Аудиторська політика — це файл YAML, що передається kube-apiserver під час запуску і відображає типи ресурсів та дієслова на рівні аудиту. Існують чотири рівні: None (без журналювання), Metadata (користувач, дієслово, ресурс, статус — без тіла), Request (додає тіло запиту) та RequestResponse (додає тіла запиту і відповіді). Аудиторська політика рівня відповідності фіксує RequestResponse для секретів, ConfigMap, Roles, RoleBindings, ClusterRoles, ClusterRoleBindings та ServiceAccounts — ресурсів, модифікація яких може свідчити про підвищення привілеїв або крадіжку облікових даних. Виклики exec та attach подів також мають фіксуватися на рівні RequestResponse, оскільки вони є основними векторами інтерактивного бокового переміщення у скомпрометованому кластері. Всі інші ресурси можна журналювати на рівні Metadata, що забезпечує повний запис доступу без накладних витрат на зберігання кожного навантаження застосунку.

Журнали аудиту, що зберігаються лише на вузлі площини управління, вразливі до фальсифікації скомпрометованим адміністратором кластера. Архітектура аудиту оборонного класу пересилає журнали до зовнішнього призначення, до якого сам кластер не може писати або видаляти: системи SIEM (системи управління інформацією та подіями безпеки), сумісного з S3 сховища об'єктів лише для додавання з утриманням об'єктів, або виділеного пересилача syslog до ізольованої інфраструктури агрегації журналів. Агент пересилання журналів — DaemonSet Fluentd або Fluent Bit на вузлах площини управління — має використовувати обліковий запис служби Kubernetes без жодних дозволів на об'єкти кластера, що журналюються, щоб скомпрометований агент не міг приховати свої сліди, змінюючи аудиторську політику або видаляючи файли журналів.

Сканування образів і безпека ланцюжка постачання у засекречених реєстрах контейнерів

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

Інструменти сканування вразливостей образів, такі як Trivy або Grype, аналізують кожен шар образу за базою даних рекомендацій OSV та бюлетенями безпеки постачальників, формуючи список CVE з оцінками серйозності та версіями уражених пакетів. У засекреченому конвеєрі CI сканування виконується як частина процесу збірки образу; образи, що містять CVE критичної або високої серйозності, блокуються від завантаження до виробничого реєстру до усунення вразливостей або їх формального прийняття як ризику. Результати сканування зберігаються поряд із образом у метаданих реєстру і посилаються в пакеті доказів акредитації як підтвердження того, що інвентаризація програмного забезпечення відома та перевірена.

Підписання образів додає криптографічне твердження про те, що конкретний дайджест образу був створений конкретним конвеєром збірки і не був змінений після підписання. Інструмент cosign проєкту Sigstore підтримує підписання з ключем, що зберігається в HSM або KMS, формуючи атестацію підпису, що зберігається в реєстрі поряд із образом. Вебхук допуску Kubernetes — за допомогою рушія політик Kyverno або OPA Gatekeeper — перевіряє підпис до планування будь-якого пода. Цей ланцюжок зберігання доказів від збірки до розгортання є саме тим, що вимагають системи безпеки ланцюжка постачання: кожне навантаження в кластері можна простежити до конкретного підписаного артефакту збірки, а непідписані або підроблені образи відхиляються на рівні допуску, а не виявляються під час посмертного криміналістичного розслідування.

Шлях до акредитації: проходження кластером Kubernetes через ATO або еквівалент

Повноваження на експлуатацію для кластера Kubernetes — це не один документ, а пакет доказів, зібраних для підтвердження того, що система відповідає засобам контролю безпеки, зазначеним у застосовній системі — Risk Management Framework (RMF) для федеральних програм США, JSIG для об'єднаних розвідувальних систем або програмно-специфічні еквіваленти для оборонних закупівель союзних держав. Уповноважена посадова особа переглядає цей пакет і приймає рішення про прийняття ризику. Розуміння того, що має містити пакет, є необхідним для планування терміну акредитації, оскільки прогалини, виявлені наприкінці процесу перевірки, можуть затримати введення в дію на місяці.

Центральним документом є План безпеки системи. Для кластера Kubernetes ПБС має описувати архітектуру кластера (кількість і розміщення вузлів площини управління, топологію etcd, пули робочих вузлів, мережеву топологію), конфігурацію посилення вузлів із посиланнями на звіт відповідності kube-bench, конфігурацію шифрування для etcd, модель RBAC (які облікові записи служб мають які дозволи і чому), архітектуру мережевих політик, ланцюжок походження та підписання образів, а також архітектуру пересилання журналів аудиту. Кожен засіб контролю у застосовній базовій лінії або виконується (з посиланням на доказ), або не застосовується (з обґрунтуванням), або є відкритим (з компенсуючим засобом контролю або записом у плані дій).

Безперервний моніторинг є умовою більшості ATO, а не одноразовим кроком. Кластер має бути включений до системи управління конфігурацією, що виявляє відхилення від посиленої базової лінії, процесу управління вразливостями, що відстежує CVE у розгорнутих образах і пакетах ОС вузлів відповідно до SLA усунення, та процесу перегляду журналів, що відстежує події аудиту на наявність аномалій. Автоматизований інструментарій — kube-bench, що запускається за розкладом як Kubernetes CronJob, повторне сканування образів щовечора, правила сповіщення SIEM для підозрілих шаблонів сервера API — формує докази безперервного моніторингу без ручних зусиль для кожного циклу перевірки. Програми, що будують цю автоматизацію до початкового подання пакету ATO, перебувають у значно кращому становищі для повторної авторизації порівняно з тими, що розглядають безперервний моніторинг як другорядне питання після авторизації.