Модуль 9.8: Глибоке занурення в управління секретами

Складність: [COMPLEX] | Час на виконання: 2 год | Передумови: Модуль 9.1 (Бази даних), Kubernetes RBAC, основи хмарного IAM

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

У грудні 2023 року розробник медичної компанії випадково завантажив файл .env із ключем доступу AWS у публічний репозиторій GitHub. Автоматичний сканер зловмисників знайшов цей ключ за 11 хвилин. На 14-й хвилині хакери вже переглядали бакети S3 з історіями хвороб пацієнтів. До 22-ї хвилини вони викрали 340 000 записів. Витік коштував компанії $4.8 мільйона штрафів та мільйони на відновлення репутації.

Причина не в “неуважності” розробника. Причина в архітектурі, яка дозволяла існування довгоживучих статичних паролів. Той ключ працював 19 місяців, його ніхто не міняв і не моніторив. Секрет зберігався в Kubernetes Secret (який за замовчуванням не шифрується, а лише кодується) та в файлі на ноутбуці.

Сучасне управління секретами повністю прибирає цей ризик. Динамічні секрети живуть лише годину і створюються “на льоту”. Оператори синхронізують паролі з хмарних сейфів прямо в пам’ять подів, а інструменти типу Sealed Secrets дозволяють безпечно зберігати секрети навіть у публічному Git.

Цей модуль навчить вас будувати “сейф” для вашого кластера. Ви дізнаєтеся про External Secrets Operator, Secrets Store CSI та легендарний HashiCorp Vault. Ви навчитеся обирати правильний підхід для вашої компанії — від простих хмарних рішень до складних систем із нульовою довірою (Zero Trust).

Проблема Kubernetes Secrets

За замовчуванням Kubernetes Secrets — це лише base64-кодування, а не шифрування. Будь-хто з доступом до kubectl get secret може миттєво прочитати ваш пароль:

kubectl get secret db-pass -o jsonpath='{.data.password}' | base64 -d
# Ви отримаєте пароль відкритим текстом

Що вам потрібно насправді:

Зберігання: Зовнішній сейф (Vault) з аудитом кожного запиту.
Ротація: Автоматична зміна паролів без перезавантаження всього кластера.
Динамічні секрети: Пароль, що створюється спеціально для одного пода і вмирає разом із ним.
GitOps-безпека: Можливість тримати секрети в Git без ризику їх витоку.

External Secrets Operator (ESO): Стандарт індустрії

ESO — це найпопулярніше рішення. Він працює як кур’єр: бере пароль із вашого хмарного менеджера (AWS Secrets Manager, Google Secret Manager) і створює звичайний Kubernetes Secret у вашому неймспейсі.

Чому це круто:

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

Dynamic Secrets із HashiCorp Vault

Це “вищий пілотаж” безпеки. Замість того, щоб дати поду статичний пароль від бази даних, який не мінявся роками:

Под запускається і просить Vault дати доступ до бази.
Vault заходить у базу і створює тимчасового користувача з унікальним паролем та лімітом часу (напр. на 1 годину).
Vault віддає ці дані поду.
Через годину Vault сам видаляє цього користувача з бази даних. Результат: Навіть якщо цей пароль вкрадуть — через годину він перетвориться на сміття.

Sealed Secrets: Секрети в Git

Якщо ви використовуєте GitOps (ArgoCD/Flux), ви хочете тримати все в Git. Але паролі туди класти не можна. Sealed Secrets дозволяють зашифрувати секрет так, що розшифрувати його зможе ТІЛЬКИ ваш кластер Kubernetes. Зашифрований файл безпечно класти в публічний репозиторій — для всіх інших це просто набір випадкових літер.

Типові помилки

Помилка	Чому це стається	Як виправити
base64 = безпека	Помилкове сприйняття формату	Пам’ятайте: base64 легко читається. Використовуйте шифрування на рівні etcd
Секрети в ConfigMaps	”Там зручніше тримати рядки підключення”	ConfigMaps пишуться в логи і не мають захисту. Тільки Secrets або Vault
Видалення секрету з Git	”Я зробив новий коміт без пароля”	Пароль залишився в історії Git! Треба змінити пароль у базі ТА очистити історію через `git-filter-repo`
Один пароль на всі поди	”Створювати кожному свій довго”	Використовуйте динамічні секрети Vault або ролі IAM на рівні подів

Тест

1. Чим відрізняється External Secrets Operator від Secrets Store CSI Driver?

ESO створює реальний об’єкт Secret у базі Kubernetes (etcd). CSI Driver не створює об’єктів, а монтує секрет безпосередньо як файл у пам’ять пода. CSI Driver вважається безпечнішим (секрети не лежать в etcd), але ESO — гнучкішим для стандартних додатків.

2. Що станеться, якщо ви втратите ключ від Sealed Secrets контролера в кластері?

Ви не зможете розшифрувати жоден секрет, який був зашифрований цим ключем. Вам доведеться перешифровувати всі паролі новим ключем. Завжди робіть бекап приватного ключа Sealed Secrets!

Практична вправа: Сейф у кластері

Встановіть ESO у свій кластер.
Налаштуйте SecretStore для вашого хмарного провайдера.
Створіть ExternalSecret, який підтягне тестовий пароль із хмари.
Перевірте, що в кластері з’явився звичайний Secret із правильним значенням.
Змініть пароль у хмарі і подивіться, через скільки секунд ESO оновить його в Kubernetes.

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

Переходьте до Модуля 9.9: Cloud-Native API Gateways та WAF — ви навчитеся захищати вхід у вашу систему, налаштовувати захист від хакерських атак та керувати трафіком мікросервісів за допомогою сучасних API-шлюзів.