Kubernetes став платформою оркестрування за замовчуванням для хмарних навантажень оборонного сектору — від контейнеризованих систем командування й управління та конвеєрів сенсорних даних до служб AI-виведення, що працюють на тактичному рівні. Це впровадження породжує проблему безпеки, яку корпоративні посібники із захисту Kubernetes не розглядають: модель загроз для військового навантаження принципово відрізняється від моделі загроз для комерційного SaaS-застосунку. Противник має ресурси рівня держави-нації, інсайдерська загроза має рівень допуску безпеки, ланцюг постачання є легітимним вектором атаки, а наслідки витоку контейнера або викрадення даних — це втрата класифікованих даних, а не штраф PCI. Стандартний корпоративний захист необхідний, але недостатній.
Цей посібник охоплює повний стек безпеки хмарних навантажень для Kubernetes у військових умовах: специфічну для оборони модель загроз, ізоляцію pod-ів, сегментацію мережі, управління секретами, захист RBAC, цілісність ланцюга постачання образів, виявлення аномалій під час виконання та автоматизацію безперервного дотримання нормативних вимог. Написано для інженерів платформ та архітекторів безпеки, що розгортають або зміцнюють Kubernetes для оборонного застосування — не для procurement-команд, що пишуть вимоги.
1. Модель загроз Kubernetes для оборони
Перш ніж вибирати засоби контролю, варто чітко визначити, від чого ви захищаєтесь. Чотири категорії загроз домінують у військових середовищах Kubernetes і вимагають різних рівнів контролю.
Ворожий інсайдер із законним доступом. В оборонному середовищі інсайдери мають допуски — тобто вони вже пройшли перевірку зі встановлення анкетних даних і мають певний рівень авторизованого доступу. Інсайдерська загроза — це не той, кому випадково надали надмірний доступ; це той, хто навмисно зловживає авторизованим доступом, можливо під примусом або через ідеологічні мотиви. Засоби контролю повинні припускати, що зловмисник може автентифікуватися законним шляхом, та покладатися на принцип найменших привілеїв, поведінковий моніторинг та незмінні журнали аудиту, а не лише на периметральну аутентифікацію.
Компрометація ланцюга постачання. Противники рівня держави-нації продемонстрували готовність компрометувати програмні ланцюги постачання вище за течією — системи збірки, пакети з відкритим кодом, базові образи контейнерів та конвеєри CI/CD. Образ контейнера, який проходить усі функціональні тести, може містити бекдор, впроваджений на рівні збірки. Засоби контролю повинні вважати кожен образ контейнера потенційно скомпрометованим до тих пір, поки перевірена криптографічна атестація не доведе зворотне, і припускати, що відомі справні образи можуть бути замінені в будь-якій точці ланцюга постачання.
Горизонтальне переміщення мережею. Кластери Kubernetes за замовчуванням дозволяють необмежений зв'язок між pod-ами в межах мережі кластера. Зловмисник, який досяг виконання коду всередині будь-якого контейнера — через вразливість у відкритому сервісі, помилку десеріалізації або скомпрометовану залежність — може негайно сканувати й атакувати кожен інший сервіс у кластері. Оборонні кластери, що обробляють навантаження кількох класифікаційних рівнів або кількох орендарів, не можуть терпіти цю поведінку за замовчуванням. Мережеві засоби контролю повинні завжди припускати компрометацію принаймні одного pod-а.
Витік контейнера. Витік контейнера — це вразливість, яка дозволяє коду, що виконується всередині контейнера, вийти за межі контейнера і виконуватися з привілеями ядра хоста або root-правами хоста. Витоки контейнерів були продемонстровані через вразливості ядра (runc CVE-2019-5736, CVE-2022-0185), неправильно налаштовані привілейовані контейнери та небезпечні монтування томів. Для класифікованих навантажень витік контейнера еквівалентний прямому доступу до хоста — та потенційно до кожного іншого навантаження на цьому вузлі. Захист під час виконання та ізоляція вузлів повинні враховувати можливість успішного витоку.
2. Безпека pod-ів: PodSecurityAdmission та захист контейнерів
Перший і найбільш прямий рівень контролю — це застосування безпеки на рівні pod-а під час допуску. Застарілий PodSecurityPolicy (PSP) був замінений у Kubernetes 1.25 вбудованим контролером PodSecurityAdmission (PSA), який є стандартним механізмом.
PSA застосовує один із трьох профілів на рівні простору імен: privileged (без обмежень), baseline (запобігає найнебезпечнішим конфігураціям) і restricted (повний захищений профіль). Для військових навантажень профіль restricted є базовою вимогою. Позначте кожен простір імен застосунку:
pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/enforce-version: latest pod-security.kubernetes.io/audit: restricted pod-security.kubernetes.io/warn: restricted
Профіль restricted застосовує: відсутність привілейованих контейнерів, відсутність спільного простору імен хоста (hostPID, hostIPC, hostNetwork), відсутність користувача root (runAsNonRoot: true), файлову систему root лише для читання (readOnlyRootFilesystem: true), скидання всіх можливостей з додаванням лише конкретних, а також профіль seccomp RuntimeDefault або Localhost.
Окрім PSA, усі контейнери повинні скидати ВСІ можливості та додавати назад лише явно необхідні. Більшості контейнерів застосунків не потрібні жодні можливості Linux. Вимога обґрунтування для будь-якого запису capabilities.add — перевіреного та схваленого командою безпеки — є процесним контролем, який запобігає непомітному послабленню захисту через поступове розповзання можливостей.
3. Мережеві політики: zero-trust комунікація між pod-ами
Мережева модель Kubernetes дозволяє будь-якому pod-у досягти будь-якого іншого pod-а за замовчуванням. Для військових навантажень це за замовчуванням потрібно інвертувати. Кожному простору імен потрібна NetworkPolicy відмови за замовчуванням, що застосовується при створенні:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: mission-workload
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
Calico та Cilium — два CNI-плагіни, придатні для оборонного використання. Calico є більш широко розгорнутим варіантом та реалізує стандартну NetworkPolicy Kubernetes, а також власний CRD GlobalNetworkPolicy для правил масштабу кластера. Cilium реалізує стандартну NetworkPolicy та додатково забезпечує політику рівня 7, DNS-базовану політику виходу та глибоку видимість через eBPF без сайдкара.
Для кластерів оборони з повітряним зазором блокування виходу є обов'язковим. Весь вихідний трафік pod-ів до зовнішніх мереж повинен бути заблокований за замовчуванням, за винятком конкретних задокументованих потоків, затверджених через процес управління змінами. DNS-базована політика виходу Cilium особливо корисна тут: замість підтримання IP-списків дозволів, які змінюються зі зміною інфраструктури, ви дозволяєте DNS-імена, що розпізнаються у вашому контрольованому внутрішньому DNS.
Багатоорендарські кластери — де навантаження різних класифікаційних рівнів співіснують на одному фізичному кластері — вимагають застосування мережевої політики, верифікованої на рівні ядра, а не лише на рівні API. Застосування eBPF Cilium відкидає заборонені пакети в стеку мережі ядра, до того як вони досягнуть застосунку, незалежно від того, чи знайшов зловмисник спосіб обійти шар kube-proxy.
4. Управління секретами: Vault, sealed secrets та KMS з апаратним забезпеченням
Секрети Kubernetes — це значення, закодовані в base64, що зберігаються в etcd. Без конвертного шифрування, підкріпленого апаратним модулем безпеки або хмарним KMS, будь-хто з доступом на читання до etcd має відкритий текстовий доступ до кожного секрету в кластері. Це неприйнятна позиція для оборонного середовища.
HashiCorp Vault є стандартним рішенням для управління секретами в оборонному Kubernetes. Vault запускається як StatefulSet у виділеному просторі імен vault-system, ізольованому NetworkPolicy від усіх просторів імен застосунків. Автоматичне розпломбовування використовує HSM (для кластерів на власному обладнанні) або хмарний KMS із апаратно підкріпленим ключовим матеріалом (для хмарних кластерів). Vault agent injector перехоплює створення pod-а та впроваджує init-контейнер vault-agent і сайдкар, які аутентифікуються у Vault за допомогою токена ServiceAccount pod-а, отримують необхідні секрети, записують їх у розміщений в пам'яті том tmpfs та підтримують їх ротацію протягом усього часу роботи pod-а.
Критична деталь конфігурації: контейнери застосунків повинні зчитувати секрети з впровадженого шляху /vault/secrets/, а не зі змінних середовища. Змінні середовища видимі в /proc/<pid>/environ для будь-якого процесу на тому ж хості з достатніми привілеями — витік контейнера негайно їх розкриває.
Sealed Secrets вирішують проблему початкового завантаження GitOps. Контролер SealedSecret у кластері тримає асиметричний ключ; ви шифруєте відкритим ключем за допомогою kubeseal, фіксуєте шифротекст у Git, і лише внутрішньокластерний контролер може розшифрувати. Sealed Secrets і Vault є взаємодоповнюючими: Sealed Secrets для статичних початкових облікових даних та конфігурації низької чутливості, Vault для всіх динамічних, високоцінних та часто ротованих секретів.
Для найвищих класифікаційних рівнів KMS, що підкріплює автоматичне розпломбовування Vault, повинен мати апаратне забезпечення — HSM рівня FIPS 140-2 Level 3 на власному обладнанні або спеціалізований HSM-сервіс хмарного провайдера (AWS CloudHSM, Azure Dedicated HSM).
5. Захист RBAC: найменші привілеї, ізоляція просторів імен, журналювання аудиту
RBAC Kubernetes за замовчуванням поводиться дозвільно кількома способами, які оборонні кластери повинні явно усунути. Кожне навантаження повинне працювати під виділеним ServiceAccount — ніколи не під service account default. Автоматичне монтування токенів повинне бути вимкнено за замовчуванням для всіх ServiceAccount та вмикатися явно лише там, де навантаженню потрібно звертатися до API Kubernetes.
Коли навантаженню все ж потрібен доступ до API, надайте мінімальний набір дієслів для мінімального набору ресурсів, обмежений власним простором імен навантаження. Жодних ClusterRoleBinding для навантажень застосунків. Ролі масштабу кластера — лише для операторів кластера, захищені робочим процесом привілейованої робочої станції з MFA та тимчасовими обліковими даними.
Журнал аудиту API-сервера Kubernetes є найважливішим криміналістичним артефактом у кластері Kubernetes. Налаштуйте його з політикою, що фіксує рівень RequestResponse для Secrets, ConfigMaps, Roles, RoleBindings, ClusterRoles та ClusterRoleBindings. Журнали аудиту повинні надсилатися в реальному часі до зовнішнього сховища журналів лише для додавання поза радіусом ураження скомпрометованого навантаження застосунку.
6. Ланцюг постачання образів: підписання Cosign, admission webhooks, приватний реєстр
Безпека ланцюга постачання образів контейнерів усуває загрозу потрапляння скомпрометованих образів у кластер. Оборонна позиція така: кожен образ повинен містити верифікований криптографічний підпис від ключа, що зберігається в контрольованому обладнанні, а непідписані образи повинні відхилятися при допуску.
Cosign (частина проекту Sigstore) прикріплює підпис до маніфесту образу OCI у реєстрі. Ключ підпису зберігається в KMS або HSM, ніколи — на CI-виконавці. Будь-який образ, який не був зібраний і підписаний контрольованим конвеєром CI, не проходить перевірку підпису.
Kyverno є рекомендованим контролером допуску для оборонного Kubernetes. ClusterPolicy застосовує верифікацію підпису, блокуючи кожне створення Pod, якщо образ не несе дійсного підпису Cosign від ключа вашої організації. Приватний реєстр — це внутрішній реєстр з повітряним зазором або ізольований брандмауером — жодного отримання з публічних реєстрів у виробничих просторах імен не дозволено. Окремий процес імпорту з верифікацією підпису та скануванням вразливостей є єдиним шляхом з публічного upstream до внутрішнього реєстру.
7. Безпека виконання: Falco, моніторинг eBPF, gVisor для ненадійних навантажень
Falco підключається до ядра через eBPF-зонд і зіставляє потік системних викликів із набором правил. Правила за замовчуванням охоплюють вимоги фреймворку MITRE ATT&CK та CIS Benchmark. Специфічні для оборони власні правила охоплюють: оболонки, запущені всередині контейнерів місіонерських навантажень, вихідні підключення з просторів імен, де вихід повинен бути заблокований, записи до чутливих шляхів та спроби ескалації привілеїв. Сповіщення Falco надсилаються до SIEM у реальному часі та інтегруються з посібниками SOAR, що автоматично ізолюють підозрілі pod-и.
gVisor вставляє ядро простору користувача між процесом контейнера та ядром хоста Linux, зменшуючи поверхню атаки ядра, доступну для витоку контейнера. Використовуйте gVisor для рівня ненадійних навантажень; використовуйте стандартні контейнери з Falco та seccomp для надійних місіонерських навантажень з жорстким бюджетом затримки.
8. Автоматизація відповідності: kube-bench, перевірки STIG, безперервне звітування
Ручні аудити відповідності дають моментальні знімки, які застарівають у момент зміни кластера. kube-bench виконує перевірки CIS Kubernetes Benchmark на живому кластері. DISA Kubernetes STIG тісно відповідає бенчмарку CIS з додатковими вимогами DoD. Запуск kube-bench як запланованого завдання та відображення результатів на ідентифікатори перевірок STIG дає автоматизовані, безперервні докази відповідності. Перевірки, що не пройшли вище певного порогу серйозності, блокують просування змін інфраструктури у конвеєрі GitOps.
Окрім kube-bench, стек відповідності включає: Trivy або Grype для CVE-сканування всіх образів у реєстрі, Checkov для статичного аналізу маніфестів Kubernetes та чартів Helm, та Polaris для поточної валідації конфігурації навантажень.
Ключовий висновок: Найпоширеніший режим відмови безпеки Kubernetes в оборонних умовах — розрив між тим, що говорить політика допуску, та тим, що фактично запущено після шести місяців операційних змін. Автоматизація безперервного дотримання нормативних вимог усуває цей розрив. Ставтеся до стану відповідності як до метрики реального часу, а не до артефакту щорічного аудиту. Для оточуючої системи безпеки дивіться повний посібник із кібербезпеки оборони.
Безпека хмарних навантажень у Kubernetes для військових застосувань — це багаторівневий набір засобів контролю, кожен з яких усуває окремий вектор загрози та повинен підтримуватися безперервно в міру розвитку кластера та його навантажень. Безпека pod-ів, мережева політика, Vault, захист RBAC, підписання образів, Falco та безперервне сканування відповідності разом формують захист оборонного рівня — кожен рівень виходить з припущення, що попередній зазнав невдачі.