Посилення Kubernetes для оборонних робочих навантажень: еталони CIS та рекомендації NSA

Kubernetes став стандартною платформою розгортання для контейнеризованих застосунків у сфері оборони — від DoD Platform One до національних оборонних хмарних програм у країнах-членах НАТО. Його впровадження в оборонних середовищах зумовлено тими самими операційними перевагами, що й у комерційному секторі: узгоджене розгортання у різних середовищах, автоматичне масштабування, самовідновлення робочих навантажень та декларативне управління інфраструктурою. Але стандартна інсталяція Kubernetes призначена для зручності, а не для безпеки — і різниця в безпеці між стандартною інсталяцією та посиленим розгортанням оборонного рівня є суттєвою.

NSA та CISA опублікували Посібник із посилення Kubernetes (v1.2, серпень 2022 р.) спеціально для заповнення цієї прогалини. Посібник охоплює посилення площини управління, мережеву безпеку, безпеку Pod, журналювання аудиту, а також аутентифікацію та авторизацію. Еталон CIS для Kubernetes надає доповнюючий, більш детальний набір перевірок конфігурації з оцінками. Разом ці два документи визначають, що означає «посилений» Kubernetes в оборонному контексті.

Посібник із посилення Kubernetes NSA/CISA: ключові рекомендації

Посібник NSA/CISA організовує рекомендації за шістьма категоріями. Найбільш операційно значущими для оборони є:

Безпека Pod Kubernetes. Pod повинні використовувати контейнери без прав root, файлові системи лише для читання та мати мінімально необхідні можливості. Привілейовані контейнери — з повним доступом до хост-системи — не повинні застосовуватися у виробничих навантаженнях.

Мережева сегрегація та посилення. Весь трафік між сервісами слід шифрувати за допомогою TLS (сервісна мережа з mTLS). Мережеві політики мають обмежувати зв'язок між Pod лише явно дозволеними шляхами. API-сервер Kubernetes не повинен бути прямо доступний з інтернету або з ненадійних мережевих сегментів.

Аутентифікація та авторизація. API-сервер не повинен дозволяти анонімну аутентифікацію або незахищені порти. Рольовий контроль доступу (RBAC) повинен бути увімкнений і налаштований за принципом найменших привілеїв. Токени облікових записів сервісів не повинні автоматично монтуватися на Pod, яким не потрібен доступ до API-сервера.

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

Частота оновлень. Версії Kubernetes отримують патчі безпеки приблизно 14 місяців після випуску. Використання непідтримуваних версій Kubernetes є значним ризиком безпеки, неприйнятним для оборонних розгортань.

Стандарти безпеки Pod: профіль Restricted

Стандарти безпеки Pod (PSS) Kubernetes визначають три профілі політики — Privileged, Baseline та Restricted — які представляють зростаючі рівні обмежень конфігурації Pod. Профіль Restricted є відповідним базовим рівнем для оборонних навантажень: він застосовує найбільш важливі з погляду безпеки обмеження конфігурації Pod.

Профіль Restricted забороняє: привілейовані контейнери, контейнери, що запускаються від root (застосовується через runAsNonRoot: true), контейнери з доступом до хост-мережі, контейнери з доступом до хост-PID або хост-IPC, контейнери, що монтують хост-шляхи як томи, та контейнери, що додають можливості Linux понад визначений дозволений список.

Реалізація профілю Restricted у наявному середовищі Kubernetes часто вимагає змін у застосунках. Для нової розробки оборонних застосунків відповідність профілю Restricted повинна бути вимогою до проектування від початку.

Стандарти безпеки Pod застосовуються через вбудований контролер допуску PodSecurity (доступний з Kubernetes 1.25). Оборонні розгортання повинні використовувати режим Enforce для профілю Restricted у всіх виробничих просторах імен.

Мережеві політики: мікросегментація за допомогою Calico або Cilium

Мережеві політики Kubernetes визначають, які Pod можуть спілкуватися з іншими Pod на рівні IP/порту. Без мережевих політик усі Pod у кластері можуть спілкуватися між собою — пласка мережева топологія, архітектурно несумісна з принципами нульової довіри. Мережеві політики реалізують шар мікросегментації на рівні мережі контейнерів.

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

Cilium використовує eBPF для застосування мережевої політики в ядрі Linux, забезпечуючи вищу продуктивність порівняно з рішеннями на основі iptables та підтримуючи мережеві політики Рівня 7. Компонент спостережуваності Hubble від Cilium забезпечує детальну видимість мережевих потоків.

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

Контролери допуску: Policy-as-Code з OPA/Gatekeeper та Kyverno

Контролери допуску — це плагіни, що перехоплюють запити до API-сервера до їх збереження в etcd, дозволяючи застосовувати політики на рівні API кластера. OPA/Gatekeeper та Kyverno є двома домінуючими фреймворками policy-as-code для контролю допуску Kubernetes.

OPA/Gatekeeper використовує рушій політик OPA з мовою політик Rego. Gatekeeper реєструється як ValidatingAdmissionWebhook, що викликає рушій політик OPA для кожного відповідного запиту до API. Шаблони обмежень визначають структуру політики; Обмеження створюють екземпляри шаблону для конкретних ресурсів.

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

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

Безпека виконання: Falco, seccomp та AppArmor

Falco (CNCF-graduated) є стандартним інструментом безпеки виконання для Kubernetes: він відстежує системні виклики ядра в реальному часі та генерує сповіщення, коли поведінка відповідає підозрілим шаблонам. Правила Falco охоплюють виконання процесів, доступ до файлів, мережеву активність та активність API Kubernetes. Falco інтегрується з SIEM-системами через syslog або Webhook.

seccomp (secure computing mode) профілі обмежують системні виклики, доступні процесам контейнерів. Kubernetes надає профіль seccomp за замовчуванням (RuntimeDefault), що блокує найнебезпечніші системні виклики. Оборонні навантаження повинні щонайменше використовувати профіль RuntimeDefault.

AppArmor (у дистрибутивах Linux, що його підтримують) надає шар обов'язкового контролю доступу, який обмежує, що кожен процес може робити з файлами, можливостями та мережевими операціями. Профілі AppArmor для контейнерів Kubernetes додають рівень захисту в глибину.