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

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

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

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

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

Увага:

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

Базове посилення безпеки

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

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

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

Службові облікові записи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Розширене посилення безпеки

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

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

Налаштуйте Security Context для pod-container.

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

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

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

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

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


Змінено March 09, 2026 at 3:31 PM PST: [uk] Ukrainian translation (all-in-one) (085108619a)

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

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