Модуль 6.2: CIS Benchmarks

Складність: [СЕРЕДНЯ] - Технічні знання

Час на виконання: 25-30 хвилин

Передумови: Модуль 6.1: Фреймворки відповідності

Що ви зможете робити

Після завершення цього модуля ви зможете:

Оцінити категорії CIS Benchmark та їх покриття безпеки площини управління, вузлів та політик
Оцінити результати бенчмарку для пріоритизації критичних та рекомендаційних висновків
Визначити як kube-bench автоматизує перевірку відповідності CIS для компонентів кластера
Пояснити зв’язок між CIS Benchmarks та ширшими фреймворками відповідності

Чому цей модуль важливий

CIS (Center for Internet Security) Kubernetes Benchmark надає приписні рекомендації безпеки для кластерів Kubernetes. Це галузевий стандарт зміцнення Kubernetes і широко використовується у вимогах відповідності.

KCSA перевіряє ваші знання категорій CIS Benchmark та ключових рекомендацій.

Що таке CIS Benchmark?

┌─────────────────────────────────────────────────────────────┐
│              CIS KUBERNETES BENCHMARK                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ЩО: Рекомендації конфігурації безпеки для Kubernetes       │
│  ВІД: Center for Internet Security                         │
│  ФОРМАТ: Приписні перевірки з рекомендаціями виправлення   │
│                                                             │
│  СТРУКТУРА:                                                │
│  ├── Компоненти площини управління                         │
│  ├── etcd                                                  │
│  ├── Конфігурація площини управління                       │
│  ├── Робочі вузли                                          │
│  └── Політики                                              │
│                                                             │
│  ОЦІНКА:                                                   │
│  ├── Scored — впливає на відсоток відповідності            │
│  └── Not Scored — лише рекомендації                        │
│                                                             │
│  ПРОФІЛІ:                                                  │
│  ├── Рівень 1 — базова безпека (мінімальне порушення)     │
│  └── Рівень 2 — захист у глибину (може вплинути на        │
│      функціональність)                                     │
│                                                             │
│  ВЕРСІЇ:                                                   │
│  • Оновлюється з кожним релізом Kubernetes                 │
│  • Керовані дистрибутиви мають специфічні бенчмарки        │
│    (EKS, GKE, AKS, OpenShift)                             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Категорії бенчмарку

1. Компоненти площини управління

┌─────────────────────────────────────────────────────────────┐
│              БЕЗПЕКА ПЛОЩИНИ УПРАВЛІННЯ                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1.2 API-СЕРВЕР                                            │
│  ├── Вимкнути анонімну автентифікацію                      │
│  ├── Увімкнути авторизацію RBAC                            │
│  ├── Вимкнути небезпечний порт                             │
│  ├── Увімкнути admission-контролери                        │
│  ├── Налаштувати журналювання аудиту                       │
│  ├── Встановити відповідні обмеження запитів               │
│  └── Увімкнути провайдери шифрування                       │
│                                                             │
│  1.3 CONTROLLER MANAGER                                    │
│  ├── Увімкнути збір сміття завершених подів                │
│  ├── Використовувати облікові дані ServiceAccount          │
│  └── Ротація токенів ServiceAccount                        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

2. etcd

┌─────────────────────────────────────────────────────────────┐
│              БЕЗПЕКА etcd                                   │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  КЛЮЧОВІ ПЕРЕВІРКИ:                                        │
│  • --cert-file та --key-file встановлені                  │
│  • --peer-cert-file та --peer-key-file встановлені        │
│  • --client-cert-auth=true                               │
│  • --peer-client-cert-auth=true                          │
│  • --auto-tls=false                                      │
│  • Дозволи файлів (700)                                   │
│  • Правильна власність (etcd:etcd)                        │
│  • Шифрування у сховищі увімкнено                         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

3. Робочі вузли

┌─────────────────────────────────────────────────────────────┐
│              БЕЗПЕКА РОБОЧИХ ВУЗЛІВ                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  КЛЮЧОВІ НАЛАШТУВАННЯ KUBELET:                             │
│  --anonymous-auth=false                                   │
│  --authorization-mode=Webhook                             │
│  --client-ca-file=/path/to/ca.crt                        │
│  --read-only-port=0                                       │
│  --protect-kernel-defaults=true                           │
│  --rotate-certificates=true                               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

4. Політики

┌─────────────────────────────────────────────────────────────┐
│              ПОЛІТИКИ KUBERNETES                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  5.1 RBAC ТА СЛУЖБОВІ ОБЛІКОВІ ЗАПИСИ                     │
│  ├── Обмежити використання ролі cluster-admin             │
│  ├── Мінімізувати доступ до секретів                      │
│  ├── Мінімізувати використання підстановочних знаків      │
│  ├── Мінімізувати доступ до створення подів               │
│  ├── Переконатися, що default SA не використовується      │
│  └── Вимкнути автомонтування токенів SA                   │
│                                                             │
│  5.2 POD SECURITY STANDARDS                                │
│  ├── Мінімізувати привілейовані контейнери                │
│  ├── Мінімізувати спільний доступ до просторів імен хоста │
│  ├── Мінімізувати запуск від root                         │
│  ├── Мінімізувати capabilities                             │
│  └── Застосувати Pod Security Standards                    │
│                                                             │
│  5.3 МЕРЕЖЕВІ ПОЛІТИКИ                                     │
│  ├── Використовувати CNI, що підтримує NetworkPolicy       │
│  ├── Визначити стандартні політики заборони                │
│  └── Забезпечити належну ізоляцію подів                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Використання kube-bench

Запуск kube-bench

# Запуск на вузлі площини управління
kube-bench run --targets master

# Запуск на робочому вузлі
kube-bench run --targets node

# Запуск конкретних перевірок
kube-bench run --targets master --check 1.2.1,1.2.2

# Вивід як JSON
kube-bench run --targets master --json

# Запуск як Kubernetes Job
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

Інтерпретація результатів

┌─────────────────────────────────────────────────────────────┐
│              ВИВІД KUBE-BENCH                               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  [PASS] = Відповідає рекомендації                         │
│  [FAIL] = Не відповідає, потрібне виправлення             │
│  [WARN] = Потрібна ручна перевірка                        │
│  [INFO] = Лише інформація                                 │
│                                                             │
│  == Summary ==                                             │
│  45 checks PASS                                            │
│  10 checks FAIL                                            │
│  5 checks WARN                                             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

CIS Benchmark для керованого Kubernetes

┌─────────────────────────────────────────────────────────────┐
│              БЕНЧМАРКИ КЕРОВАНОГО KUBERNETES                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ЧОМУ ВІДРІЗНЯЮТЬСЯ?                                       │
│  • Площина управління керується провайдером                │
│  • Доступні різні опції конфігурації                       │
│  • Модель спільної відповідальності                        │
│                                                             │
│  EKS BENCHMARK                                             │
│  • Рекомендації, специфічні для AWS                        │
│  • Інтеграція IAM                                          │
│  • kube-bench підтримує: --benchmark eks-1.0              │
│                                                             │
│  GKE BENCHMARK                                             │
│  • Рекомендації, специфічні для GCP                        │
│  • Workload Identity                                       │
│  • kube-bench підтримує: --benchmark gke-1.0              │
│                                                             │
│  AKS BENCHMARK                                             │
│  • Рекомендації, специфічні для Azure                      │
│  • Інтеграція Azure AD                                     │
│  • kube-bench підтримує: --benchmark aks-1.0              │
│                                                             │
│  ВІДПОВІДАЛЬНІСТЬ:                                         │
│  Провайдер: Компоненти площини управління                  │
│  Клієнт: Робочі вузли, навантаження, політики             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Чи знали ви?

CIS Benchmarks базуються на консенсусі — вони розробляються фахівцями з безпеки з кількох організацій та представляють узгоджені найкращі практики.
Не всі перевірки застосовні до всіх середовищ. Керований Kubernetes (EKS, GKE, AKS) має інші бенчмарки, тому що клієнти не контролюють площину управління.
kube-bench може працювати як под — вам не потрібен SSH-доступ до вузлів для перевірки відповідності.
Контролі Рівня 2 можуть впливати на функціональність. Наприклад, обмеження syscalls через seccomp може зламати деякі застосунки.

Поширені помилки

Помилка	Чому це шкодить	Рішення
Ігнорування ручних перевірок	Пропуск вразливостей	Переглянути елементи WARN
Сліпе застосування всіх контролів	Може зламати кластер	Спочатку тестувати у non-prod
Запуск лише раз	Дрейф з часом	Планувати регулярні скани
Без відстеження прогресу	Не видно покращень	Побудувати дашборд відповідності
Рівне ставлення до всіх невдач	Неефективне виправлення	Пріоритизувати за ризиком

Перевірка знань

Що таке CIS Kubernetes Benchmark?

Відповідь
Приписні рекомендації конфігурації безпеки для Kubernetes, розроблені Center for Internet Security. Він надає конкретні рекомендації для зміцнення кластерів Kubernetes щодо компонентів площини управління, etcd, робочих вузлів та політик.
Яка різниця між бенчмарками Рівня 1 та Рівня 2?

Відповідь
Рівень 1 забезпечує базову безпеку з мінімальним впливом на роботу або функціональність системи. Рівень 2 забезпечує захист у глибину з потенційно більш обмежувальними налаштуваннями, які можуть вплинути на функціональність. Рівень 1 — мінімальна планка; Рівень 2 — для більш безпечних середовищ.
Чому слід вимкнути анонімну автентифікацію на API-сервері?

Відповідь
Анонімна автентифікація дозволяє неавтентифіковані запити до API-сервера. Навіть при наявності авторизації, це збільшує поверхню атаки і може призвести до витоку інформації через неавтентифіковані точки доступу. Вимкнення гарантує, що всі запити до API мають бути автентифіковані.
Чому керований Kubernetes має інші бенчмарки?

Відповідь
У керованому Kubernetes (EKS, GKE, AKS) хмарний провайдер управляє площиною управління. Клієнти не можуть налаштовувати багато параметрів API-сервера, etcd або controller-manager. Керовані бенчмарки зосереджені на тому, що клієнти можуть контролювати: робочі вузли, навантаження та політики.
Як kube-bench допомагає з відповідністю?

Відповідь
kube-bench автоматизує перевірки CIS Benchmark. Він сканує компоненти кластера відповідно до рекомендацій бенчмарку, звітує статуси PASS/FAIL/WARN та надає рекомендації виправлення. Він може працювати на вузлах або як под, підтримує різні версії Kubernetes та керовані платформи, та видає звіти для документації відповідності.

Підсумок

CIS Benchmark надає стандарти безпеки Kubernetes:

Категорія	Ключові сфери
Площина управління	Автентифікація API-сервера, авторизація, admission, аудит
etcd	TLS, автентифікація, шифрування
Робочі вузли	Автентифікація kubelet, авторизація, порт тільки для читання
Політики	RBAC, Pod Security, мережеві політики

Ключові практики:

Регулярно запускайте kube-bench
Пріоритизуйте знахідки за ризиком
Тестуйте виправлення перед застосуванням
Відстежуйте відповідність з часом
Використовуйте специфічні для керованих платформ бенчмарки

Наступний модуль

Модуль 6.3: Оцінка безпеки — Проведення та реагування на оцінки безпеки.