Список перевірки безпеки застосунків

Список перевірки безпеки застосунків

Базові рекомендації щодо забезпечення безпеки застосунків у Kubernetes, орієнтовані на розробників застосунків.

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

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

  • Порядок тем не відображає пріоритетність.
  • Деякі пункти списку детально описані в абзаці нижче списку кожного розділу.
  • Цей список передбачає, що розробник — це користувач кластера Kubernetes, який взаємодіє з обʼєктами в межах простору імен.

Увага:

Самих лише списків перевірки не достатньо для досягнення належного рівня безпеки. Належний рівень безпеки потребує постійної уваги та вдосконалення, але список перевірки може бути першим кроком на нескінченному шляху до готовності в питаннях безпеки. Деякі рекомендації в цьому списку можуть бути занадто суворими або занадто мʼякими для ваших конкретних потреб у безпеці. Оскільки безпека Kubernetes не є універсальною, кожну категорію пунктів списку слід оцінювати окремо.

Базове зміцнення безпеки

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

Дизайн застосунків

  • Дотримуйтеся відповідних принципів безпеки під час проєктування застосунків.
  • Застосунок налаштовано з відповідним класом QoS через запити й обмеження ресурсів.
  • Для робочих навантажень встановлено обмеження памʼяті, яке дорівнює запиту або перевищує його.
  • Для чутливих робочих навантажень можна встановити обмеження CPU.

ServiceAccount

  • Уникайте використання ServiceAccount default. Створюйте ServiceAccount для кожного робочого навантаження або мікросервісу.
  • automountServiceAccountToken слід встановити в false, якщо Podʼу не потрібен доступ до API Kubernetes для роботи.

Рекомендації для securityContext на рівні Podʼа

  • Встановіть runAsNonRoot: true.
  • Налаштуйте контейнер на виконання від імені менш привілейованого користувача (наприклад, за допомогою runAsUser і runAsGroup) і налаштуйте відповідні дозволи на файли або теки в образі контейнера.
  • За потреби додайте допоміжну групу через fsGroup для доступу до постійних томів.
  • Застосунок розгортається в просторі імен, де застосовується відповідний стандарт безпеки Podʼів. Якщо ви не можете контролювати це застосування в кластерах, де розгортається застосунок, врахуйте це в документації або через додатковий багаторівневий захист (defense in depth).

Рекомендації для securityContext на рівні контейнера

  • Вимкніть підвищення привілеїв за допомогою allowPrivilegeEscalation: false.
  • Налаштуйте кореневу файлову систему лише для читання за допомогою readOnlyRootFilesystem: true.
  • Уникайте запуску привілейованих контейнерів (встановіть privileged: false).
  • Вилучіть усі capabilities з контейнерів і поверніть лише ті, які потрібні для роботи контейнера.

Контроль доступу на основі ролей (RBAC)

  • Дозволи, такі як create, patch, update і delete, слід надавати лише за потребою.
  • Уникайте дозволів RBAC на створення або оновлення ролей, що може призвести до підвищення привілеїв.
  • Перегляньте привʼязки для групи system:unauthenticated і видаліть їх, якщо можливо, оскільки це надає доступ будь-кому, хто може підʼєднатися до API-сервера на мережевому рівні.

Дієслова create, update і delete слід дозволяти виважено. Дієслово patch, якщо його дозволено для Namespace, може дозволити користувачам оновлювати мітки простору імен або Deployments, що може збільшити поверхню атаки.

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

Безпека образів

  • Використовуйте інструмент для сканування образів перед розгортанням контейнерів у кластері Kubernetes.
  • Використовуйте підписування контейнерів для перевірки підпису образу контейнера перед розгортанням у кластері Kubernetes.

Мережеві політики

  • Налаштуйте NetworkPolicies, щоб дозволити лише очікуваний вхідний та вихідний трафік Podʼів.

Переконайтеся, що ваш кластер підтримує та застосовує NetworkPolicy. Якщо ви пишете застосунок, який користувачі розгортатимуть у різних кластерах, подумайте, чи можна припускати, що NetworkPolicy доступна й застосовується.

Розширене зміцнення безпеки

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

Безпека контейнерів Linux

Налаштуйте контекст безпеки для Podʼа й контейнера.

Класи виконання

  • Налаштуйте відповідні класи виконання для контейнерів.
Примітка: Цей розділ містить посилання на проєкти сторонніх розробників, які надають функціонал, необхідний для Kubernetes. Автори проєкту Kubernetes не несуть відповідальності за ці проєкти. Проєкти вказано в алфавітному порядку. Щоб додати проєкт до цього списку, ознайомтеся з посібником з контенту перед надсиланням змін. Докладніше.

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

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

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

Змінено November 02, 2026 at 9:16 AM PST: [uk] Add security: secrets-good-practices, application-security-checklist, pod-security-admission (1c3a027dc1)

Елементи на цій сторінці відносяться до сторонніх продуктів чи проєктів, які надають функціонал, необхідний для Kubernetes. Автори проєкту Kubernetes не несуть відповідальності за ці проєкти. Ознайомтесь з настановами на вебсайті CNCF для отримання докладної інформації.

Ознайомтесь з посібником з контенту перед тим, як пропонувати додавання посилання на стороні компоненти.