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

Цей список перевірки спрямований на надання основних рекомендацій з безпеки застосунків, що працюють у 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.

• Встановіть профілі Seccomp для контейнерів.
• Обмежте доступ контейнера до ресурсів за допомогою AppArmor.
• Призначте відповідні мітки SELinux контейнерам.

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

• Налаштуйте відповідні класи виконання для контейнерів.

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

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

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