Модуль 3.3: Управління секретами

Складність: [СЕРЕДНЯ] - Основні знання

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

Передумови: Модуль 3.2: Основи RBAC

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

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

Оцінити обмеження безпеки Kubernetes Secrets (кодування base64, зберігання в etcd)
Оцінити стратегії управління секретами: шифрування у спокої, зовнішні сховища секретів, sealed secrets
Визначити поширені ризики витоку секретів: витік через змінні середовища, надмірний RBAC-доступ, незашифрований etcd
Пояснити як реалізувати шифрування у спокої та інтегрувати зовнішні інструменти управління секретами

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

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

Огляд секретів Kubernetes

┌─────────────────────────────────────────────────────────────┐
│              СЕКРЕТИ KUBERNETES                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ЩО ТАКЕ СЕКРЕТИ:                                          │
│  • Сховище ключ-значення для чутливих даних                │
│  • Монтуються у поди як файли або змінні середовища        │
│  • Окремо від конфігурації застосунку (ConfigMaps)         │
│                                                             │
│  ЩО СЕКРЕТИ НЕ Є:                                          │
│  • Шифровані за замовчуванням (лише base64)                │
│  • Захищені від користувачів з дозволом get secrets        │
│  • Повним рішенням для управління секретами                │
│                                                             │
│  ВАЖЛИВА ПОМИЛКА:                                          │
│  Base64 =/= Шифрування                                     │
│  Base64 - це кодування, не безпека!                         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Використання секретів у подах

Змінні середовища проти томів

┌─────────────────────────────────────────────────────────────┐
│              ЗМІННІ СЕРЕДОВИЩА проти ТОМІВ                   │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ЗМІННІ СЕРЕДОВИЩА                                         │
│  ├── Плюси: Просто використовувати у застосунку            │
│  └── Мінуси:                                               │
│      ├── Видимі в /proc/<pid>/environ                      │
│      ├── Часто випадково логуються                          │
│      ├── Успадковуються дочірніми процесами                 │
│      └── Не оновлюються при зміні секрету                  │
│                                                             │
│  МОНТУВАННЯ ТОМІВ                                          │
│  ├── Плюси:                                                │
│  │   ├── Можна монтувати лише для читання                  │
│  │   ├── Оновлюються при зміні секрету                     │
│  │   └── Менш ймовірно випадково залогувати                │
│  └── Мінуси: Потрібне читання файлів у застосунку          │
│                                                             │
│  РЕКОМЕНДАЦІЯ: Надавайте перевагу томам для чутливих даних │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Шифрування у спокої

Увімкніть шифрування для захисту секретів у etcd:

# EncryptionConfiguration
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>
      - identity: {}  # Резервний для незашифрованих

Провайдери шифрування

Провайдер	Опис	Випадок використання
`identity`	Без шифрування	Ніколи для секретів
`aescbc`	Шифрування AES-CBC	Самокеровані кластери
`aesgcm`	Шифрування AES-GCM	Швидше за aescbc
`kms`	Зовнішнє KMS	Продакшн, відповідність
`secretbox`	XSalsa20 + Poly1305	Альтернатива AES

Зовнішні менеджери секретів

Для продакшн розгляньте зовнішні менеджери секретів:

┌─────────────────────────────────────────────────────────────┐
│              ЗОВНІШНІ МЕНЕДЖЕРИ СЕКРЕТІВ                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  HASHICORP VAULT                                           │
│  ├── Повнофункціональне управління секретами                │
│  ├── Динамічні секрети (короткотривалі)                    │
│  ├── Шифрування як сервіс                                  │
│  └── Метод автентифікації Kubernetes                        │
│                                                             │
│  СЕКРЕТИ ХМАРНИХ ПРОВАЙДЕРІВ                               │
│  ├── AWS Secrets Manager                                   │
│  ├── GCP Secret Manager                                    │
│  ├── Azure Key Vault                                       │
│  └── Інтеграція через CSI driver                           │
│                                                             │
│  ОПЕРАТОРИ KUBERNETES                                      │
│  ├── External Secrets Operator                             │
│  ├── Secrets Store CSI Driver                              │
│  └── Синхронізація зовнішніх секретів у K8s Secrets        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Чи знали ви?

Base64 - не шифрування - воно тривіально зворотне. echo "cGFzc3dvcmQ=" | base64 -d миттєво дає оригінальне значення.
Секрети зберігаються в etcd разом з усіма іншими об’єктами Kubernetes. Якщо etcd скомпрометовано, скомпрометовані і всі секрети.
ClusterRole view не включає секрети за задумом для надання широкого доступу на читання без розкриття чутливих даних.
Оновлення секретів поширюються до змонтованих томів з часом (~1 хвилина), але змінні середовища вимагають перезапуску поду.

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

Помилка	Чому це шкодить	Рішення
Вважати base64 = шифрування	Секрети читаються будь-ким з доступом	Шифрування у спокої
Секрети у змінних середовища	Логуються, видимі в /proc	Томи
Секрети у Git	Постійне розкриття	sealed-secrets або зовнішній менеджер
Широкий `get secrets` RBAC	Всі секрети доступні	Ізоляція просторів імен
Без ротації	Скомпрометовані секрети залишаються дійсними	Процес ротації

Тест

Чому кодування base64 недостатнє для захисту секретів?

Відповідь
Base64 - це кодування, не шифрування. Воно тривіально зворотне - будь-хто, хто може прочитати значення base64, може його декодувати. Воно не забезпечує безпеки, лише зручність для роботи з бінарними даними.
Що відбувається з секретами при увімкненні шифрування у спокої?

Відповідь
Секрети шифруються перед збереженням в etcd. Навіть якщо сховище etcd скомпрометоване, секрети захищені шифруванням. Для їх розшифрування потрібен ключ шифрування.
Чому монтування томів переважніше за змінні середовища для секретів?

Відповідь
Змінні середовища видимі в /proc, часто випадково логуються, успадковуються дочірніми процесами та не оновлюються при зміні секретів. Томи більш безпечні та оновлюються при зміні секретів.
Що таке конвертне шифрування в контексті KMS?

Відповідь
Конвертне шифрування використовує два ключі: DEK шифрує дані, а KEK у KMS шифрує DEK. Це дозволяє ротацію ключів без перешифрування всіх даних та зберігає майстер-ключ у безпечному обладнанні.
Який дозвіл RBAC дозволяє читати всі секрети у просторі імен?

Відповідь
Verb `get` на ресурсі `secrets`. У Kubernetes RBAC немає контролю доступу для окремих секретів - ви або можете читати секрети, або ні. Використовуйте ізоляцію просторів імен для обмеження обсягу.

Підсумок

Аспект	Поведінка за замовчуванням	Найкраща практика
Зберігання	Base64 в etcd	Шифрування у спокої
Доступ	Контроль RBAC	Мінімізувати get secrets
Використання	Змінні або том	Томи
Життєвий цикл	Без ротації	Впровадити ротацію
Зовнішнє	Не інтегровано	Зовнішній менеджер

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

Модуль 3.4: Безпека ServiceAccount - Захист ідентифікації подів та доступу до API.