Список перевірок безпеки

Цей список має на меті надати базовий перелік рекомендацій з посиланнями на більш комплексну документацію з кожної теми. Він не претендує на повноту і може змінюватись.

Як користуватись цим документом:

• Порядок тем не відображає порядок пріоритетів.
• Деякі пункти списку розкриваються в абзац нижче переліку кожної секції.

Автентифікація та авторизація

• Група system:masters не використовується для автентифікації користувачів чи компонентів після першого налаштування.
• Компонент kube-controller-manager працює з увімкненим параметром --use-service-account-credentials.
• Кореневий сертифікат захищений (або офлайн CA, або керований онлайн CA з ефективними елементами керування доступом).
• Проміжний та листовий сертифікати мають строк дії не більше ніж 3 роки вперед.
• Існує процес періодичного перегляду доступу, і перегляди проводяться не рідше ніж через кожні 24 місяці.
• Дотримуються рекомендації щодо контролю доступу на основі ролей щодо автентифікації та авторизації.

Після першої налаштування ні користувачі, ні компоненти не повинні автентифікуватися в API Kubernetes як system:masters. Так само, варто уникати використання всіх компонентів kube-controller-manager як system:masters. Фактично, system:masters повинен використовуватися лише як механізм для виходу з аварійної ситуації, а не як адміністративний користувач.

Безпека мережі

• Використані CNI-втулки підтримують політики мережі.
• Політики мережі вхідного та вихідного трафіку застосовані до всіх навантажень в кластері.
• У кожному просторі імен встановлені типові політики мережі, які вибирають всі Podʼи та забороняють все.
• У разі необхідності використано сервісну сітку (service mesh) для шифрування всіх зʼєднань всередині кластера.
• API Kubernetes, API kubelet та etcd не викладені публічно в Інтернеті.
• Доступ від навантажень до API хмарних метаданих фільтрується.
• Використання LoadBalancer та ExternalIPs обмежено.

Багато втулків мережевого інтерфейсу контейнера (CNI) забезпечують функціональність обмеження ресурсів мережі, з якими можуть спілкуватися Podʼи. Найчастіше це робиться за допомогою мережевих політик, які надають ресурс з простором імен для визначення правил. Типові політики мережі, які блокують вхідний та вихідний трафік, у кожному просторі імен, вибираючи всі Podʼи, можуть бути корисні для прийняття списку дозволів, щоб переконатися, що жодне навантаження не пропущене.

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

Дані etcd панелі управління повинні мати елементи для обмеження доступу і не повинні бути публічно викладені в Інтернеті. Крім того, для безпечного звʼязку з нею має використовуватись взаємний TLS (mTLS). Центр сертифікації для цього повинен бути унікальним для etcd.

Зовнішній Інтернет-доступ до сервера API Kubernetes повинен бути обмежений, щоб не викладати API публічно. Будьте обережні, оскільки багато дистрибутивів Kubernetes, що надаються постачальниками послуг, стандартно викладають сервер API публічно. Потім можна використовувати хост-бастион для доступу до сервера.

Доступ до API kubelet повинен бути обмежений і не викладений публічно, стандартні налаштування автентифікації та авторизації, коли не вказаний файл конфігурації з прапорцем --config, є занадто дозвільними.

Якщо для розміщення Kubernetes використовується хмарний провайдер, доступ від навантажень до API хмарних метаданих 169.254.169.254 також повинен бути обмежений або заблокований, якщо він не потрібний, оскільки це може робити можливим витік інформації.

Для обмеженого використання LoadBalancer та ExternalIPs див. CVE-2020-8554: Man in the middle using LoadBalancer or ExternalIPs та контролер відмови ExternalIPs для отримання додаткової інформації.

Безпека Podʼів

• Права RBAC create, update, patch, delete навантажень надаються лише за необхідності.
• Для всіх просторів імен застосована та використовується відповідна політика стандартів безпеки Podʼів.
• Ліміт памʼяті встановлено для навантажень з обмеженням, рівним або меншим за запит.
• Ліміт CPU може бути встановлено для чутливих навантажень.
• Для вузлів, що його підтримують, увімкнено Seccomp з відповідними профілями syscalls для програм.
• Для вузлів, що його підтримують, увімкнено AppArmor або SELinux з відповідним профілем для програм.

Авторизація RBAC є важливою, але не може бути достатньо гранульованою для надання авторизації ресурсам Podʼів (або будь-якому ресурсу, який керує Podʼами). Єдиною гранулярністю є дії API на сам ресурс, наприклад, створення Podʼів. Без додаткового допуску, авторизація на створення цих ресурсів дозволяє прямий необмежений доступ до призначених для планування вузлів кластера.

Стандарти безпеки Podʼів визначають три різних політики: privileged, baseline та restricted, які обмежують, як поля можуть бути встановлені в PodSpec щодо безпеки. Ці стандарти можуть бути накладені на рівні простору імен за допомогою нового допуску безпеки Podʼів, ввімкненого стандартно, або за допомогою стороннього вебхуку допуску. Зауважте, що, на відміну від видаленого PodSecurityPolicy, яке він замінює, допуск безпеки Podʼів може легко поєднуватися з вебхуками допусків та зовнішніми службами.

Політика restricted безпеки Podʼів, найбільш обмежувальна політика зі стандартного набору безпеки Podʼів, може працювати у кількох режимах, warn, audit або enforce, щоб поступово застосовувати найбільш відповідний контекст безпеки відповідно до найкращих практик з безпеки. З усім тим, контекст безпеки Podʼів повинен окремо досліджуватися для обмеження привілеїв та доступу, які можуть мати Podʼи, крім попередньо визначених стандартів безпеки, для конкретних випадків використання.

Для підручника з безпеки Podʼів див. блог пост Kubernetes 1.23: Політика безпеки Podʼів переходить до бета-версії.

Ліміти памʼяті та CPU повинні бути встановлені для обмеження памʼяті та CPU, які може споживати Pod на вузлі, та, отже, запобігають можливим атакам DoS від зловмисних або порушених робочих навантажень. Така політика може бути накладена контролером допуску. Зверніть увагу, що ліміти CPU будуть обмежувати використання і можуть мати непередбачені наслідки для функцій автоматичного масштабування або ефективності, тобто виконання процесу з найкращими спробами з доступними ресурсами CPU.

Увімкнення Seccomp

Seccomp (secure computing mode) є функцією ядра Linux з версії 2.6.12. Він може бути використаний для ізоляції привілеїв процесу, обмежуючи виклики, які він може зробити з простору користувача в ядро. Kubernetes дозволяє автоматично застосовувати профілі seccomp, завантажені на вузол, до ваших Podʼів і контейнерів.

Seccomp може покращити безпеку вашого навантаження, зменшуючи доступну для атак на ядро Linux поверхню викликів системного виклику всередині контейнерів. Режим фільтрації seccomp використовує BPF для створення списку дозволених або заборонених конкретних системних викликів, які називаються профілями.

Починаючи з Kubernetes 1.27, ви можете увімкнути використання RuntimeDefault як типового профілю seccomp для всіх навантажень. Існує посібник з безпеки на цю тему. Крім того, Оператор профілів безпеки Kubernetes — це проєкт, який сприяє управлінню та використанню seccomp в кластерах.

Увімкнення AppArmor або SELinux

AppArmor

AppArmor — це модуль безпеки ядра Linux, який може забезпечити простий спосіб реалізації обовʼязкового контролю доступу (MAC, Mandatory Access Control) та кращого аудиту через системні логи. На вузлах, які його підтримують, застосовується стандартний профіль AppArmor, або може бути налаштований власний профіль. Як і seccomp, AppArmor також налаштовується через профілі, де кожен профіль працює в посиленому режимі, який блокує доступ до заборонених ресурсів, або в режимі скарг, який лише повідомляє про порушення. Профілі AppArmor застосовуються на рівні контейнера з анотацією, що дозволяє процесам отримати лише необхідні привілеї.

SELinux

SELinux також є модулем безпеки ядра Linux, який може забезпечити механізм для підтримки політик безпеки контролю доступу, включаючи обовʼязковий контроль доступу (MAC). Мітки SELinux можуть бути призначені для контейнерів або Podʼів через їх розділ securityContext.

Логи та аудит

• Логи аудиту, якщо вони увімкнені, захищені від загального доступу.

Розташування Podʼів

• Розташування Podʼів виконане відповідно до рівнів чутливості застосунку.
• Чутливі застосунки працюють в ізольованому вигляді на вузлах або зі специфічними середовищами виконання, розміщеними в пісочниці.

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

Селектори вузла

Пари ключ-значення, як частина специфікації Podʼів, що вказують, на які вузли їх розгорнути. Це може бути встановлено на рівні простору імен та кластера за допомогою контролера допуску PodNodeSelector.

PodTolerationRestriction

Контролер допуску, який дозволяє адміністраторам обмежувати дозволені толерантності в межах простору імен. Podʼів в межах простору імен можуть використовувати тільки толерантності, вказані в ключах анотацій обʼєктів простору імен, які надають типовий та дозволений набір толерантностей.

RuntimeClass

RuntimeClass — це функція для вибору конфігурації контейнера для запуску. Конфігурація контейнера використовується для запуску контейнерів Podʼів і може забезпечувати більшу або меншу ізоляцію від хосту коштом продуктивності.

Secret

• ConfigMap не використовуються для зберігання конфіденційних даних.
• Шифрування у спокої для Secret API налаштоване.
• Якщо це необхідно, механізм для вбудовування Secret, збережених у сторонньому сховищі, розгорнуто та доступний.
• Токени облікового запису служби не монтується в Podʼах, які не потребують їх.
• Використовується привʼязанний том токенів облікового запису служби замість нескінченних токенів.

Secret, необхідні для Podʼів, повинні зберігатися у Secretʼах Kubernetes, на відміну від альтернатив, таких як ConfigMap. Ресурси Secret, збережені в etcd, повинні бути зашифровані у спокої.

Podʼи, що потребують Secret, повинні автоматично мати їх змонтовані через томи, попередньо збережені у памʼяті, наприклад, за допомогою опції emptyDir.medium. Механізм може бути використаний також для введення Secret зі сторонніх сховищ як томів, наприклад, Secrets Store CSI Driver. Це слід робити переважно порівняно з наданням Podʼам облікових записів служб доступу RBAC до Secret. Це дозволить додавати Secret до Podʼів як змінні середовища або файли. Зверніть увагу, що метод змінних середовища може бути більш схильним до витоку через аварійні записи в логах та неконфіденційний характер змінної середовища в Linux, на відміну від механізму дозволу на файли.

Токени облікових записів служби не повинні монтуватися в Podʼи, які не потребують їх. Це можна налаштувати, встановивши automountServiceAccountToken в значення false або для облікового запису служби, щоб застосувати це на всі простори імен або конкретно для Podʼа. Для Kubernetes v1.22 і новіше використовуйте привʼязані облікові записи служб для часово обмежених облікових записів служби.

Образи

• Мінімізувати непотрібний вміст у образах контейнера.
• Контейнерні образи налаштовані на запуск з правами непривілейованого користувача.
• Посилання на контейнерні образи виконуються за допомогою хешів sha256 (замість міток), або походження образу перевіряється шляхом перевірки цифрового підпису образу під час розгортання через контролер допуску.
• Контейнерні образи регулярно скануються під час створення та розгортання, і відоме вразливе програмне забезпечення піддається патчингу.

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

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

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

Сканування контейнерних образів може запобігти розгортанню критичних вразливостей у кластері разом з контейнерним образом. Сканування образів повинно бути завершено перед розгортанням контейнерного образу в кластері та, як правило, виконується як частина процесу розгортання у CI/CD конвеєрі. Метою сканування образу є отримання інформації про можливі вразливості та їх запобігання в контейнерному образі, такої як оцінка Загальної системи оцінки вразливостей (CVSS). Якщо результати сканування образів поєднуються з правилами відповідності конвеєра, операційне середовище буде використовувати лише належно виправлені контейнерні образи.

Контролери допуску

• Включено відповідний вибір контролерів допуску.
• Політика безпеки підпорядкована контролеру допуску про безпеку або/і вебхуку контролера допуску.
• Втулки ланцюжка допуску та вебхуки надійно налаштовані.

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

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

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

CertificateApproval

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

CertificateSigning

Здійснює додаткові перевірки авторизації, щоб переконатися, що користувач, який підписує, має дозвіл на підписування запитів на отримання сертифіката.

CertificateSubjectRestriction

Відхиляє будь-який запит на сертифікат, який вказує 'групу' (або 'організаційний атрибут') system:masters.

LimitRanger

Застосовує обмеження API-контролера обмежень.

MutatingAdmissionWebhook

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

PodSecurity

Заміна політики безпеки контейнера, обмежує контексти безпеки розгорнутих контейнерів.

ResourceQuota

Застосовує обмеження ресурсів для запобігання перевикористанню ресурсів.

ValidatingAdmissionWebhook

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

Друга група включає втулки, які типово не увімкнені, але знаходяться в стані загальної доступності та рекомендуються для покращення вашої безпеки:

DenyServiceExternalIPs

Відхиляє всю нову мережеву взаємодію з полем Service.spec.externalIPs. Це захист від CVE-2020-8554: Man in the middle using LoadBalancer or ExternalIPs.

NodeRestriction

Обмежує дозволи kubelet тільки на модифікацію ресурсів API для точок доступу керування мережевими підключеннями, якими він володіє або ресурсу API вузла, які представляють себе. Він також заважає використанню kubelet анотації node-restriction.kubernetes.io/, яку може використовувати зловмисник з доступом до облікових даних kubelet, щоб вплинути на розміщення Podʼа на вузлі.

Третя група включає втулки, які за стандартно не увімкнені, але можуть бути розглянуті для певних випадків використання:

AlwaysPullImages

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

ImagePolicyWebhook

Дозволяє застосовувати додаткові контролери для образів через вебхуки.

Що далі

• Підвищення привілеїв через створення Podʼа попереджає вас про конкретний ризик контролю доступу; перевірте, як ви управляєте цією загрозою.
  • Якщо ви використовуєте use Kubernetes RBAC ознайомтьесь з Порадами з використання RBAC для додаткової інформації щодо авторизації.
• Захист кластера для інформації щодо захисту кластера від випадкового або зловмисного доступу.
• Керівництво з мультиорендності кластера для рекомендацій та найкращих практик щодо конфігурації опцій та багатоорендності.
• Стаття в блозі "Докладніше про рекомендації посилення безпеки Kubernetes від NSA/CISA" для додаткових ресурсів з посилення безпеки кластерів Kubernetes.