# Список перевірок безпеки > Базовий список для забезпечення безпеки в кластерах Kubernetes. --- LLMS index: [llms.txt](/llms.txt) --- Цей список має на меті надати базовий перелік рекомендацій з посиланнями на більш комплексну документацію з кожної теми. Він не претендує на повноту і може змінюватись. Як користуватись цим документом: - Порядок тем не відображає порядок пріоритетів. - Деякі пункти списку розкриваються в абзац нижче переліку кожної секції.

Увага:

Списки не є достатніми для досягнення хорошої позиції безпеки самі по собі. Для забезпечення відповідного рівня безпеки потрібна постійна увага і вдосконалення, але список може бути першим кроком на нескінченному шляху до безпеки. Деякі рекомендації у цьому списку можуть бути занадто обмежувальними або надто слабкими для вашої конкретної потреби у безпеці. Оскільки безпека Kubernetes не є "однорозмірною", кожна категорія пунктів списку повинна оцінюватися відповідно.
## Автентифікація та авторизація {#authentication-authorization} - [ ] Група `system:masters` не використовується для автентифікації користувачів чи компонентів після першого налаштування. - [ ] Компонент kube-controller-manager працює з увімкненим параметром `--use-service-account-credentials`. - [ ] Кореневий сертифікат захищений (або офлайн CA, або керований онлайн CA з ефективними елементами керування доступом). - [ ] Проміжний та листовий сертифікати мають строк дії не більше ніж 3 роки вперед. - [ ] Існує процес періодичного перегляду доступу, і перегляди проводяться не рідше ніж через кожні 24 місяці. - [ ] Дотримуються [рекомендації щодо контролю доступу на основі ролей](/docs/concepts/security/rbac-good-practices/) щодо автентифікації та авторизації. Після початкового налаштування ні користувачі, ні компоненти не повинні автентифікуватися в API Kubernetes як `system:masters`. Так само, варто уникати запуску всього kube-controller-manager від імені `system:masters`. Фактично, `system:masters` повинен використовуватися лише як механізм аварійного доступу, а не як адміністративний користувач. ## Безпека мережі {#network-security} - [ ] CNI-втулки, що використовуються, підтримують політики мережі. - [ ] Політики мережі вхідного та вихідного трафіку застосовані до всіх навантажень в кластері. - [ ] У кожному просторі імен встановлені типові політики мережі, які вибирають всі Podʼи та забороняють все. - [ ] У разі необхідності використано сервісну мережу (service mesh) для шифрування всіх зʼєднань всередині кластера. - [ ] API Kubernetes, API kubelet та etcd не експоновані публічно в Інтернеті. - [ ] Доступ від навантажень до API хмарних метаданих фільтрується. - [ ] Використання LoadBalancer та ExternalIPs обмежено. Багато [втулків мережевого інтерфейсу контейнера (CNI)](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) забезпечують функціональність обмеження ресурсів мережі, з якими можуть спілкуватися Podʼи. Найчастіше це робиться за допомогою [мережевих політик](/docs/concepts/services-networking/network-policies/), які надають ресурс з простором імен для визначення правил. Типові політики мережі, які блокують вхідний та вихідний трафік, у кожному просторі імен, вибираючи всі Podʼи, можуть бути корисні для застосування підходу зі списком дозволів, щоб переконатися, що жодне навантаження не пропущене. Не всі CNI-втулки надають шифрування під час транзиту. Якщо обраний втулок не має цієї функції, альтернативним рішенням може бути використання сервісної мережі для надання цієї функціональності. База даних etcd панелі управління повинна мати засоби контролю для обмеження доступу і не повинна бути відкритою для загального доступу в Інтернеті. Крім того, для безпечного звʼязку з нею має використовуватись взаємний TLS (mTLS). Центр сертифікації для цього повинен бути унікальним для etcd. Зовнішній Інтернет-доступ до сервера API Kubernetes повинен бути обмежений, щоб не експонувати API публічно. Будьте обережні, оскільки багато дистрибутивів Kubernetes, що надаються постачальниками послуг, типово експонують сервер API публічно. Потім можна використовувати хост-бастіон для доступу до сервера. Доступ до API [kubelet](/docs/reference/command-line-tools-reference/kubelet/) повинен бути обмежений і не експонований публічно, стандартні налаштування автентифікації та авторизації, коли не вказаний файл конфігурації з прапорцем `--config`, є занадто дозвільними. Якщо для розміщення Kubernetes використовується хмарний провайдер, доступ від навантажень до API хмарних метаданих `169.254.169.254` також повинен бути обмежений або заблокований, якщо він не потрібний, оскільки це може призвести до витоку інформації. Для обмеженого використання LoadBalancer та ExternalIPs див. [CVE-2020-8554: Man in the middle using LoadBalancer or ExternalIPs](https://github.com/kubernetes/kubernetes/issues/97076) та [контролер відмови ExternalIPs](/docs/reference/access-authn-authz/admission-controllers/#denyserviceexternalips) для отримання додаткової інформації. ## Безпека Podʼів {#pod-security} - [ ] Права RBAC `create`, `update`, `patch`, `delete` навантажень надаються лише за необхідності. - [ ] Для всіх просторів імен застосована та використовується відповідна політика стандартів безпеки Podʼів. - [ ] Ліміт памʼяті встановлено для навантажень з обмеженням, рівним або меншим за запит. - [ ] Ліміт CPU може бути встановлено для чутливих навантажень. - [ ] Для вузлів, що його підтримують, увімкнено Seccomp з відповідними профілями syscalls для програм. - [ ] Для вузлів, що його підтримують, увімкнено AppArmor або SELinux з відповідним профілем для програм. Авторизація RBAC є важливою, але [не може бути достатньо гранульованою](/docs/concepts/security/rbac-good-practices/#workload-creation) для надання авторизації ресурсам Podʼів (або будь-якому ресурсу, який керує Podʼами). Єдиною гранулярністю є дії API на сам ресурс, наприклад, `створення` Podʼів. Без додаткового допуску, авторизація на створення цих ресурсів дозволяє прямий необмежений доступ до призначених для планування вузлів кластера. [Стандарти безпеки Podʼів](/docs/concepts/security/pod-security-standards/) визначають три різних політики: privileged, baseline та restricted, які обмежують, які поля можуть бути встановлені в `PodSpec` щодо безпеки. Ці стандарти можуть бути накладені на рівні простору імен за допомогою нового допуску [безпеки Podʼів](/docs/concepts/security/pod-security-admission/), ввімкненого типово, або за допомогою стороннього вебхуку допуску. Зауважте, що, на відміну від видаленого PodSecurityPolicy, яке він замінює, допуск [безпеки Podʼів](/docs/concepts/security/pod-security-admission/) може легко поєднуватися з вебхуками допусків та зовнішніми службами. Політика `restricted` безпеки Podʼів, найбільш обмежувальна політика зі [стандартного набору безпеки Podʼів](/docs/concepts/security/pod-security-standards/), [може працювати у кількох режимах](/docs/concepts/security/pod-security-admission/#pod-security-admission-labels-for-namespaces), `warn`, `audit` або `enforce`, щоб поступово застосовувати найбільш відповідний [контекст безпеки](/docs/tasks/configure-pod-container/security-context/) відповідно до найкращих практик з безпеки. З усім тим, [контекст безпеки Podʼів](/docs/tasks/configure-pod-container/security-context/) повинен окремо досліджуватися для обмеження привілеїв та доступу, які можуть мати Podʼи, крім попередньо визначених стандартів безпеки, для конкретних випадків використання. Для практичного посібника з [безпеки Podʼів](/docs/concepts/security/pod-security-admission/) див. допис у блозі [Kubernetes 1.23: Політика безпеки Podʼів переходить до бета-версії](/blog/2021/12/09/pod-security-admission-beta/). [Ліміти памʼяті та CPU](/docs/concepts/configuration/manage-resources-containers/) повинні бути встановлені для обмеження памʼяті та CPU, які може споживати Pod на вузлі, та запобігання можливим атакам DoS від зловмисних або скомпрометованих робочих навантажень. Така політика може бути накладена контролером допуску. Зверніть увагу, що ліміти CPU будуть обмежувати використання і можуть мати непередбачені наслідки для функцій автоматичного масштабування або ефективності, тобто виконання процесу з найкращими спробами з доступними ресурсами CPU.

Увага:

Обмеження памʼяті, що перевищує запит, може наразити весь вузол на проблеми OOM.
### Увімкнення Seccomp {#enabling-seccomp} Seccomp (secure computing mode) є функцією ядра Linux з версії 2.6.12. Він може бути використаний для ізоляції привілеїв процесу, обмежуючи виклики, які він може зробити з простору користувача в ядро. Kubernetes дозволяє автоматично застосовувати профілі seccomp, завантажені на вузол, до ваших Podʼів і контейнерів. Seccomp може покращити безпеку ваших навантажень, зменшуючи доступну для атак на ядро Linux поверхню системних викликів всередині контейнерів. Режим фільтрації seccomp використовує BPF для створення профілів — списків дозволених або заборонених конкретних системних викликів. Починаючи з Kubernetes 1.27, ви можете увімкнути використання `RuntimeDefault` як типового профілю seccomp для всіх навантажень. Існує [посібник з безпеки](/docs/tutorials/security/seccomp/) на цю тему. Крім того, [Оператор профілів безпеки Kubernetes](https://github.com/kubernetes-sigs/security-profiles-operator) — це проєкт, який сприяє управлінню та використанню seccomp в кластерах.

Примітка:

Seccomp доступний тільки на вузлах Linux.
### Увімкнення AppArmor або SELinux {#enabling-apparmor-or-selinux} #### AppArmor [AppArmor](/docs/tutorials/security/apparmor/) — це модуль безпеки ядра Linux, який може забезпечити простий спосіб реалізації обовʼязкового контролю доступу (MAC, Mandatory Access Control) та кращого аудиту через системні логи. На вузлах, які його підтримують, застосовується стандартний профіль AppArmor, або може бути налаштований власний профіль. Як і seccomp, AppArmor також налаштовується через профілі, де кожен профіль працює в посиленому режимі, який блокує доступ до заборонених ресурсів, або в режимі скарг, який лише повідомляє про порушення. Профілі AppArmor застосовуються на рівні контейнера з анотацією, що дозволяє процесам отримати лише необхідні привілеї.

Примітка:

AppArmor доступний тільки на вузлах Linux і увімкнений в деяких дистрибутивах Linux.
#### SELinux [SELinux](https://github.com/SELinuxProject/selinux-notebook/blob/main/src/selinux_overview.md) також є модулем безпеки ядра Linux, який може забезпечити механізм для підтримки політик безпеки контролю доступу, включаючи обовʼязковий контроль доступу (MAC). Мітки SELinux можуть бути призначені для контейнерів або Podʼів [через їх розділ `securityContext`](/docs/tasks/configure-pod-container/security-context/#assign-selinux-labels-to-a-container).

Примітка:

SELinux доступний тільки на вузлах Linux і увімкнений в деяких дистрибутивах Linux.
## Логи та аудит {#logs-and-auditing} - [ ] Логи аудиту, якщо вони увімкнені, захищені від загального доступу. ## Розташування Podʼів {#pod-placement} - [ ] Розташування Podʼів виконане відповідно до рівнів чутливості застосунку. - [ ] Чутливі застосунки працюють в ізольованому вигляді на вузлах або зі специфічними середовищами виконання, розміщеними в пісочниці. Podʼи, які належать до різних рівнів чутливості, наприклад, Podʼи застосунку та сервера Kubernetes API, повинні бути розгорнуті на окремих вузлах. Метою ізоляції вузла є запобігання тому, щоб вихід з контейнера застосунку не надав зловмиснику прямого доступу до застосунків з вищим рівнем чутливості, дозволяючи легко переміщуватися в кластері. Це розділення повинно бути накладене для запобігання помилкового розгортання Podʼів на той самий вузол. Це можна забезпечити за допомогою таких функцій: [Селектори вузла](/docs/concepts/scheduling-eviction/assign-pod-node/) : Пари ключ-значення, як частина специфікації Podʼів, що вказують, на які вузли їх розгорнути. Це може бути встановлено на рівні простору імен та кластера за допомогою контролера допуску [PodNodeSelector](/docs/reference/access-authn-authz/admission-controllers/#podnodeselector). [PodTolerationRestriction](/docs/reference/access-authn-authz/admission-controllers/#podtolerationrestriction) : Контролер допуску, який дозволяє адміністраторам обмежувати дозволені [толерантності](/docs/concepts/scheduling-eviction/taint-and-toleration/) в межах простору імен. Podʼів в межах простору імен можуть використовувати тільки толерантності, вказані в ключах анотацій обʼєктів простору імен, які надають типовий та дозволений набір толерантностей. [RuntimeClass](/docs/concepts/containers/runtime-class/) : RuntimeClass — це функція для вибору конфігурації середовища виконання контейнерів. Конфігурація середовища виконання використовується для запуску контейнерів Podʼів і може забезпечувати більшу або меншу ізоляцію від хосту ціною продуктивності. ## Secret {#secrets} - [ ] ConfigMap не використовуються для зберігання конфіденційних даних. - [ ] Шифрування у спокої для Secret API налаштоване. - [ ] Якщо це необхідно, механізм для вбудовування Secret, збережених у сторонньому сховищі, розгорнуто та він є доступним. - [ ] Токени службового облікового запису не монтуються в Podʼах, які їх не потребують. - [ ] Використовується [привʼязаний том токенів службового облікового запису](/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume) замість токенів, що не закінчуються. Secret, необхідні для Podʼів, повинні зберігатися у Secretʼах Kubernetes, на відміну від альтернатив, таких як ConfigMap. Ресурси Secret, збережені в etcd, повинні бути [зашифровані у спокої](/docs/tasks/administer-cluster/encrypt-data/). Podʼи, які потребують секретів, повинні мати їх автоматично змонтованими через томи, бажано збереженими в памʼяті, наприклад, за допомогою опції [`emptyDir.medium`](/docs/concepts/storage/volumes/#emptydir). Механізм також може використовуватися для інʼєкції секретів із сторонніх сховищ як томів, наприклад, [Secrets Store CSI Driver](https://secrets-store-csi-driver.sigs.k8s.io/). Рекомендується робити це, а не надавати службовому обліковому запису podʼів доступ RBAC до секретів. Це дозволить додавати Secret до Podʼів як змінні середовища або файли. Зверніть увагу, що метод змінних середовища може бути більш схильним до витоку через аварійні записи в логах та неконфіденційний характер змінної середовища в Linux, на відміну від механізму дозволу на файли. Токени службових облікових записів не повинні монтуватися в Podʼи, які не потребують їх. Це можна налаштувати, встановивши [`automountServiceAccountToken`](/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server) в значення `false` або для службового облікового запису, щоб застосувати це на всі простори імен або конкретно для Podʼа. Для Kubernetes v1.22 і новіше використовуйте [привʼязані службові облікові записи](/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume) для часово обмежених службових облікових записів. ## Образи {#images} - [ ] Мінімізувати непотрібний вміст в образах контейнера. - [ ] Контейнерні образи налаштовані на запуск з правами непривілейованого користувача. - [ ] Посилання на контейнерні образи виконуються за допомогою хешів sha256 (замість міток), або походження образу перевіряється шляхом перевірки цифрового підпису образу під час розгортання [через контролер допуску](/docs/tasks/administer-cluster/verify-signed-artifacts/#verifying-image-signatures-with-admission-controller). - [ ] Контейнерні образи регулярно скануються під час створення та розгортання, і відоме вразливе програмне забезпечення піддається патчингу. Контейнерний образ має містити мінімум необхідного для запуску програми, яку він упаковує. Найкраще, тільки програму та її залежності, створюючи образи з мінімально можливою базою. Зокрема, образи, які використовуються в операційній діяльності, не повинні містити оболонки або засоби налагодження, оскільки для усунення несправностей може використовуватися [ефемерний контейнер для налагодження](/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container). Побудуйте образи для прямого запуску від непривілейованого користувача, використовуючи інструкцію [`USER` у Dockerfile](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user). [Контекст безпеки](/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod) дозволяє запускати контейнерні образи з певним користувачем та групою за допомогою параметрів `runAsUser` та `runAsGroup`, навіть якщо вони не вказані у маніфесті образу. Однак дозволи на файли у шарах образів можуть зробити неможливим просто запуск процесу з новим непривілейованим користувачем без модифікації образу. Уникайте використання міток для посилання на образи, особливо мітки `latest`. Образи з міткою можуть бути легко змінені у реєстрі. Краще використовувати повний хеш sha256, який унікальний для маніфесту образу. Цю політику можна накладати за допомогою [ImagePolicyWebhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook). Підписи образів також можуть бути автоматично [перевірені контролером допуску](/docs/tasks/administer-cluster/verify-signed-artifacts/#verifying-image-signatures-with-admission-controller) під час розгортання для перевірки їх автентичності та цілісності. Сканування контейнерних образів може запобігти розгортанню критичних вразливостей у кластері разом з контейнерним образом. Сканування образів повинно бути завершено перед розгортанням контейнерного образу в кластері та, як правило, виконується як частина процесу розгортання у CI/CD конвеєрі. Метою сканування образу є отримання інформації про можливі вразливості та їх запобігання в контейнерному образі, такої як оцінка [Загальної системи оцінки вразливостей (CVSS)](https://www.first.org/cvss/). Якщо результати сканування образів поєднуються з правилами відповідності конвеєра, операційне середовище буде використовувати лише належно виправлені контейнерні образи. ## Контролери допуску {#admission-controllers} - [ ] Увімкнено відповідний набір контролерів допуску. - [ ] Політика безпеки Podʼів застосовується допуском безпеки Podʼів або/і вебхуком контролера допуску. - [ ] Втулки ланцюжка допуску та вебхуки надійно налаштовані. Контролери допуску можуть допомогти покращити безпеку кластера. Однак вони можуть представляти ризики самі по собі, оскільки розширюють API-сервер і [повинні бути належним чином захищені](/blog/2022/01/19/secure-your-admission-controllers-and-webhooks/). У наступних списках наведено кілька контролерів допуску, які можуть бути розглянуті для покращення безпеки вашого кластера та застосунків. Вони включають контролери, на які є посилання в інших частинах цього документа. Ця перша група контролерів допуску включає втулки, [типово увімкнені](/docs/reference/access-authn-authz/admission-controllers/#which-plugins-are-enabled-by-default), розгляньте можливість залишити їх увімкненими, якщо ви розумієте, що робите: [`CertificateApproval`](/docs/reference/access-authn-authz/admission-controllers/#certificateapproval) : Здійснює додаткові перевірки авторизації, щоб переконатися, що користувач, який затверджує, має дозвіл на затвердження запиту на отримання сертифіката. [`CertificateSigning`](/docs/reference/access-authn-authz/admission-controllers/#certificatesigning) : Здійснює додаткові перевірки авторизації, щоб переконатися, що користувач, який підписує, має дозвіл на підписування запитів на отримання сертифіката. [`CertificateSubjectRestriction`](/docs/reference/access-authn-authz/admission-controllers/#certificatesubjectrestriction) : Відхиляє будь-який запит на сертифікат, який вказує 'групу' (або 'організаційний атрибут') `system:masters`. [`LimitRanger`](/docs/reference/access-authn-authz/admission-controllers/#limitranger) : Застосовує обмеження, визначені API LimitRange. [`MutatingAdmissionWebhook`](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) : Дозволяє використання власних контролерів через вебхуки, ці контролери можуть змінювати запити, які вони переглядають. [`PodSecurity`](/docs/reference/access-authn-authz/admission-controllers/#podsecurity) : Заміна політики безпеки контейнера, обмежує контексти безпеки розгорнутих контейнерів. [`ResourceQuota`](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) : Застосовує обмеження ресурсів для запобігання перевикористанню ресурсів. [`ValidatingAdmissionWebhook`](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook) : Дозволяє використання власних контролерів через вебхуки, ці контролери не змінюють запити, які вони переглядають. Друга група включає втулки, які типово не увімкнені, але знаходяться в стані загальної доступності та рекомендуються для покращення вашої безпеки: [`DenyServiceExternalIPs`](/docs/reference/access-authn-authz/admission-controllers/#denyserviceexternalips) : Відхиляє будь-яке нове використання поля `Service.spec.externalIPs`. Це захист від [CVE-2020-8554: Man in the middle using LoadBalancer or ExternalIPs](https://github.com/kubernetes/kubernetes/issues/97076). [`NodeRestriction`](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) : Обмежує дозволи kubelet лише зміною ресурсів API подів, які йому належать, або ресурсу API вузла, що представляє сам kubelet. Це також не дозволяє kubelet використовувати анотацію node-restriction.kubernetes.io/; зловмисник, який має доступ до облікових даних kubelet, міг би використати цю анотацію для впливу на розміщення подів на контрольованому вузлі. Третя група включає втулки, які типово не увімкнені, але можуть бути розглянуті для певних випадків використання: [`AlwaysPullImages`](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) : Застосовує використання останньої версії мітки образу та перевіряє, чи має той, хто здійснює розгортання, дозволи на використання образу. [`ImagePolicyWebhook`](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) : Дозволяє застосовувати додаткові контролери для образів через вебхуки. ## Що далі - [Підвищення привілеїв через створення Podʼа](/docs/reference/access-authn-authz/authorization/#privilege-escalation-via-pod-creation) попереджає вас про конкретний ризик контролю доступу; перевірте, як ви управляєте цією загрозою. - Якщо ви використовуєте Kubernetes RBAC, ознайомтесь з [Порадами з використання RBAC](/docs/concepts/security/rbac-good-practices/) для додаткової інформації щодо авторизації. - [Захист кластера](/docs/tasks/administer-cluster/securing-a-cluster/) для інформації щодо захисту кластера від випадкового або зловмисного доступу. - [Керівництво з мультиорендності кластера](/docs/concepts/security/multi-tenancy/) для рекомендацій та найкращих практик щодо опцій конфігурації багатоорендності. - [Допис у блозі "Докладніше про рекомендації посилення безпеки Kubernetes від NSA/CISA"](/blog/2021/10/05/nsa-cisa-kubernetes-hardening-guidance/#building-secure-container-images) для додаткових ресурсів з посилення безпеки кластерів Kubernetes.