Кожен кластер Kubernetes постачається з вбудованим об’єктом «Secret». Схоже на безпеку. Це відчувається як безпека. Це не безпека.
Секрет Kubernetes за замовчуванням — це просто рядок у кодуванні base64, що зберігається в etcd — його читає будь-хто, хто має доступ до кластера, і легко декодується за допомогою однорядкового коду: echo "c2VjcmV0" | основа64 -d. Якщо ви явно не ввімкнули шифрування в стані спокою (а більшість команд цього не зробили), ваші паролі бази даних, маркери API та приватні ключі TLS зберігаються в незашифрованому вигляді в сховищі даних рівня керування вашого кластера. Закріпіть маніфест Kubernetes, що містить «Секрет», у Git, і ці облікові дані назавжди залишаться в історії вашого сховища.
Це проблема, для вирішення якої з’явилося нове покоління інструментів керування секретами — і в 2026 році екосистема значно зросла. Цей посібник охоплює шість найважливіших інструментів для керування секретами в середовищах Kubernetes: що вони роблять, чого не роблять і який з них відповідає рівню зрілості вашої команди.
Пов’язане: Якщо вас турбує витік секретів через ваш конвеєр CI/CD, перегляньте наш підбір найкращих інструментів конвеєра CI/CD. Щоб отримати ширшу картину безпеки контейнера, перегляньте наш посібник із інструментів сканування вразливостей.
Чому стандартні секрети Kubernetes не відповідають вимогам
Перш ніж занурюватися в інструменти, варто точно визначити, чого не вистачає в Kubernetes Secrets — адже розуміння прогалини — це те, що дозволить вам вибрати правильне рішення.
За замовчуванням без шифрування в режимі спокою. etcd зберігає секрети Kubernetes як base64, без шифрування. Увімкнення шифрування в стані спокою — це крок конфігурації на рівні кластера, який керовані постачальники Kubernetes (EKS, GKE, AKE) обробляють по-іншому, і багато самокерованих кластерів пропускають його повністю.
Немає секретної ротації. Немає вбудованого механізму, за допомогою якого секрет Kubernetes міг би знати, що його резервні облікові дані змінилися. Ви змінюєте пароль бази даних назовні, і ваші модулі продовжують використовувати старий, доки ви вручну не оновите Secret і не перезапустите уражені модулі.
Немає журналу аудиту для таємного доступу. Стандартне ведення журналу аудиту Kubernetes записує модифікації секретного об’єкта, але більшість конфігурацій не реєструють окремі зчитування, тобто ви не можете відповісти на питання «яка служба отримала доступ до цього маркера та коли?»
Git-ворожий за дизайном. Стандартна порада: «ніколи не передавайте секрети Git». Але у світі GitOps, де все як код є метою, це болісний виняток для підтримки.
RBAC як грубий інструмент. Kubernetes RBAC дозволяє надавати або забороняти доступ до секретних об’єктів на рівні простору імен. Він не може виражати «Сервіс А може читати секрет X, але не секрет Y» або «цей секрет діє через 24 години».
Жодна з цих причин не є причиною відмовитися від Kubernetes — це причина використовувати спеціальні інструменти для керування секретами на додачу до нього.
TL;DR — Порівняння функцій
| Інструмент | Шифрування в спокої | Динамічні секрети | Журнали аудиту | Рідний K8s | Multi-Cloud | Ціноутворення |
|---|---|---|---|---|---|---|
| HashiCorp Vault | ✅ | ✅ | ✅ | ⚠️ (через агента) | ✅ | OSS безкоштовно / HCP платно |
| Зовнішній секретний оператор | ✅ (через бекенд) | ✅ (через бекенд) | ✅ (через бекенд) | ✅ | ✅ | Безкоштовно / OSS |
| Запечатані секрети | ✅ | ❌ | ❌ | ✅ | ❌ | Безкоштовно / OSS |
| Менеджер секретів AWS | ✅ | ✅ | ✅ | ⚠️ (через ESO/CSI) | ❌ (лише для AWS) | Секретна ціна |
| Доплер | ✅ | ❌ | ✅ | ✅ (оператор) | ✅ | Безкоштовні → платні рівні |
| Infisical | ✅ | ✅ | ✅ | ✅ (оператор) | ✅ | OSS / хмара платна |
⚠️ = потрібні додаткові компоненти
1. HashiCorp Vault — Золотий стандарт корпоративних секретів
HashiCorp Vault — це еталон, за яким оцінюється будь-який інший інструмент керування секретами. Він пройшов бойові випробування в корпоративних середовищах протягом майже десяти років, і його набір функцій відображає цю глибину.
Основною можливістю Vault є динамічні секрети — облікові дані, які генеруються на вимогу та автоматично закінчуються. Замість того, щоб зберігати статичний пароль PostgreSQL, Vault генерує унікальну пару ім’я користувача/пароль для кожної запитуючої служби, дійсну протягом настроюваного періоду оренди (наприклад, одна година). Коли термін оренди закінчується, облікові дані відкликаються. Це усуває цілі класи розповсюдження облікових даних і значно спрощує стримування взломів.
Для Kubernetes шляхами інтеграції є Vault Agent Injector або Vault Secrets Operator. Інжектор працює як змінний вебхук, який автоматично підключає до ваших модулів агента Vault, який автентифікується в Vault за допомогою облікового запису служби Kubernetes модуля та записує секрети в спільний том у пам’яті. Оператор секретів сховища (VSO), новіший підхід, синхронізує секрети сховища з рідними секретними об’єктами Kubernetes — більш звичними для операторів, за рахунок секретів, які короткочасно існують у etcd.
Секретні механізми Vault охоплюють вражаючий діапазон:
- Облікові дані бази даних (PostgreSQL, MySQL, MongoDB тощо)
- Динамічні облікові дані AWS, GCP, Azure
- Генерація сертифікатів PKI і TLS
- Підписання сертифіката SSH
- Токени сервісного облікового запису Kubernetes
Що Vault працює добре: Динамічні облікові дані, чіткі політики доступу, повний журнал аудиту та зріла екосистема плагінів. Якщо вам потрібне керування секретами на рівні відповідності з повним відстеженням того, хто, до чого, коли отримував доступ, часто єдиним розумним варіантом є Сейф.
**На що слід звернути увагу: ** Сейф має складну роботу. Щоб запустити його в режимі високої доступності, потрібно приділяти особливу увагу серверним частинам сховища (тепер рекомендованим вибором є Raft), процедурам розпечатування та шляхам оновлення. Крива навчання реальна. Бюджет часу на розробку платформи.
Ціна: Версія з відкритим вихідним кодом є безкоштовною та відповідає більшості потреб. Хмарна платформа HashiCorp (HCP) Vault — це керована пропозиція з ціною на основі годин роботи кластера та секретних операцій. Зміна ліцензії BSL у 2023 році призвела до розгалуження OpenTofu для Terraform, але еквівалент розгалуження Vault (OpenBao) все ще розвивається.
📚 Рекомендуємо прочитати: Злом Kubernetes Ендрю Мартіна та Майкла Гаузенбласа — чудове висвітлення поверхонь для атак Kubernetes, включаючи таємні сценарії викрадання.
2. Зовнішній секретний оператор (ESO) — Рівень інтеграції K8s
External Secrets Operator має принципово іншу архітектурну позицію: замість того, щоб сам бути сховищем секретів, він є мостом між Kubernetes і зовнішнім сховищем, яке у вас уже є. ESO синхронізує секрети з диспетчера секретів AWS, диспетчера секретів GCP, сховища ключів Azure, сховища HashiCorp, 1Password, Doppler та зростаючого списку інших серверних модулів у власні секретні об’єкти Kubernetes.
Основною абстракцією є спеціальний ресурс ExternalSecret:
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: database-credentials
spec:
refreshInterval: 1h
secretStoreRef:
name: aws-secrets-manager
kind: ClusterSecretStore
target:
name: db-creds
data:
- secretKey: password
remoteRef:
key: production/db/password
ESO спостерігає за цим ресурсом, отримує секрет із менеджера секретів AWS (або де завгодно) і створює стандартний секрет Kubernetes. Ваша програма читає db-creds так само, як і будь-який інший секрет Kubernetes — не потрібно змінювати код. Коли позначається refreshInterval, ESO повторно отримує та автоматично оновлює секрет.
Чому ESO така популярна у 2026 році: вона добре поєднується з наявними інвестиціями. У вашій організації вже є AWS Secrets Manager (або Vault, або GCP Secret Manager) — ESO просто робить ці секрети доступними для використання в Kubernetes, не змінюючи код програми чи наявні робочі процеси ротації секретів.
ESO чи Vault Secrets Operator? Якщо ви використовуєте Vault, VSO має тіснішу інтеграцію з Vault (динамічні секрети Vault, Vault PKI). Якщо ви користуєтеся рідним секретним сховищем хмарного провайдера, ESO є чистішим вибором. Багато команд використовують обидва: ESO для статичних секретів, що зберігаються в хмарі, VSO для динамічних облікових даних, керованих Vault.
Ціни: ESO є безкоштовним і відкритим вихідним кодом (Apache 2.0), підтримується проектом ізольованого програмного середовища CNCF із сильною підтримкою спільноти.
3. Захищені секрети — зашифровані секрети, зручні для GitOps
Sealed Secrets від Bitnami вирішує конкретну проблему: як зберегти секретні маніфести Kubernetes у Git, не зберігаючи фактичний відкритий текст? Відповідь полягає в асиметричному шифруванні.
Контролер Sealed Secrets працює у вашому кластері та містить закритий ключ. CLI kubeseal шифрує секретний маніфест Kubernetes за допомогою відкритого ключа кластера, створюючи CRD SealedSecret. Цей зашифрований маніфест можна безпечно закріпити в Git — лише приватний ключ кластера може розшифрувати його, і його можна розшифрувати лише в цьому конкретному кластері (за замовчуванням зашифрований текст прив’язаний до простору імен + імені).
# Encrypt a secret for Git storage
kubectl create secret generic db-creds \
--from-literal=password=s3cr3t \
--dry-run=client -o yaml | \
kubeseal --format=yaml > db-creds-sealed.yaml
# This file is safe to commit
git add db-creds-sealed.yaml
Коли ви застосовуєте SealedSecret до кластера, контролер розшифровує його та створює відповідний об’єкт Secret.
Що Sealed Secrets добре робить: робочі процеси GitOps. Якщо ви використовуєте Argo CD або Flux і хочете, щоб кожен ресурс кластера (включаючи секрети) декларативно зберігався в Git, Sealed Secrets ідеально підходить для цієї моделі. Він не вимагає жодних зовнішніх залежностей за межами контролера в кластері.
Чого він не робить: Ротація, динамічні облікові дані або ведення журналів аудиту поза стандартними подіями Kubernetes. Sealed Secrets — це рішення для зберігання Git, а не повна платформа керування секретами. Якщо ваш пароль зміниться, ви повторно зашифруєте його та зафіксуєте його знову.
Резервне копіювання приватного ключа має вирішальне значення. Якщо ви втратите приватний ключ контролера, ви втратите можливість розшифровувати свої запечатані секрети. Зробіть резервну копію секрету sealed-secrets-key в окремому безпечному місці.
Ціна: Повністю безкоштовний і відкритий код (Apache 2.0).
4. AWS Secrets Manager з Kubernetes
Якщо ваші робочі навантаження виконуються в основному на EKS (або інтенсивно підключаються до служб AWS), AWS Secrets Manager у поєднанні з Secrets Store CSI Driver або External Secrets Operator цілком підійде. Ви зберігаєте секрети в керованому зашифрованому сховищі AWS, що реєструється під час аудиту, і за потреби завантажуєте їх у Kubernetes.
Драйвер CSI для сховища секретів (SSCSID) — це підхід, який підтримується CNCF: секрети монтуються безпосередньо в модулі як файли через том CSI, ніколи не записуються в etcd як секретні об’єкти Kubernetes. Це шлях із найвищим рівнем безпеки — секрети існують у пам’яті модулів, але не в секретному сховищі Kubernetes.
volumes:
- name: secrets-store
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: aws-secrets
Власні можливості AWS Secrets Manager включають автоматичну ротацію для підтримуваних служб (RDS, Redshift, DocumentDB і через Lambda для спеціальної ротації), доступ між обліковими записами та глибоку інтеграцію CloudTrail для журналів аудиту відповідності.
Врахування вартості: AWS Secrets Manager стягує плату за секрет на місяць і за виклик API. Для великих автопарків із багатьма маленькими секретами витрати можуть зрости. Перегляньте наш посібник з оптимізації витрат на хмару, щоб дізнатися про стратегії керування витратами на секретні AWS.
Найкраще для: рідних команд EKS, які вже інвестували в екосистему AWS, які хочуть тісної інтеграції IAM і рідної ротації облікових даних RDS.
5. Doppler — Developer-First SaaS Secrets Platform
Doppler використовує SaaS-перший підхід, який надає перевагу досвіду розробника над операційною складністю. Ви визначаєте секрети в інтерфейсі користувача Doppler (або через CLI/API), упорядковуєте їх за середовищем (dev, staging, production), а оператор Doppler Kubernetes автоматично синхронізує їх із секретами Kubernetes.
Оператор запитує Doppler щодо змін і оновлює відповідний секрет Kubernetes, за бажанням запускаючи перезапуск модуля, коли секрети змінюються. Налаштування — це встановлення однієї діаграми Helm:
helm repo add doppler https://helm.doppler.com
helm install --generate-name doppler/doppler-kubernetes-operator
Там, де сяє Doppler: Локальна розробка та інтеграція CI/CD разом із Kubernetes. Doppler CLI повністю замінює файли середовища (doppler run -- your-command), надаючи однакові секрети в локальному, CI та робочому середовищах. Для конвеєрів CI/CD власна інтеграція Doppler з GitHub Actions, CircleCI та іншими усуває необхідність копіювати секрети в змінні середовища конвеєра.
Що не охоплює Doppler: облікові дані динамічної бази даних. Doppler — це сховище статичних секретів з історією версій і журналами аудиту — це не система генерування секретів, як Vault.
Ціна: Doppler пропонує безкоштовний рівень для невеликих команд. Платні плани додають SSO, запити на доступ і функції відповідності. Перевірте сторінку цін Doppler, щоб дізнатися про поточні рівні (зміни цін; перевірте перед бюджетом).
6. Infisical — Альтернатива сховища з відкритим вихідним кодом
Infisical є найсильнішим конкурентом дуополії Vault/Doppler із відкритим кодом. Він надає веб-інтерфейс користувача, CLI, пакети SDK і оператор Kubernetes — розгортання на самому хості або споживається як хмарний сервіс.
Infisical додав підтримку динамічних секретів у 2024 році, націлену на генерацію облікових даних бази даних, подібно до механізму секретів бази даних Vault. Оператор Infisical Kubernetes синхронізує CRD InfisicalSecret із рідними секретами Kubernetes із настроюваними інтервалами оновлення.
Для команд, які хочуть використовувати UX на рівні SaaS (веб-панель, робочі процеси запитів на доступ, журнали аудиту), але не можуть використовувати зовнішню SaaS через вимоги відповідності, Infisical з власним розміщенням є переконливим. Керувати ним значно легше, ніж із Vault, і він зручніший для розробників.
Ціна: Ядро з відкритим кодом є безкоштовним. Хмарна версія має безкоштовний рівень і платні плани для розширених функцій. Ліцензія на власне розміщення підприємства доступна для середовищ із важкими вимогами відповідності.
📚 Для глибшого занурення в архітектуру безпеки Kubernetes: Безпека та спостережуваність Kubernetes на Amazon охоплює секрети, RBAC, мережеву політику та безпеку під час виконання в одній цілісній структурі.
Поради щодо впровадження
Почніть із шифрування в стані спокою. Перш ніж додавати додаткові інструменти, увімкніть шифрування Kubernetes etcd у стані спокою. Для керованих кластерів це часто один прапорець. Для самокерованих кластерів дотримуйтеся офіційного посібника. Це відразу підвищує базовий рівень безпеки.
Використовуйте RBAC із найменшими привілеями для Secrets. Перевірте, які облікові записи служби мають дозволи «отримувати», «списувати» або «переглядати» секретні об’єкти. Сервісні облікові записи за замовчуванням у багатьох діаграмах Helm мають надлишок ресурсів. Затягніть RBAC перед поворотом на зовнішній накопичувач.
Сплануйте свої таємні імена завчасно. Секрети швидко поширюються. Послідовна ієрархія ({env}/{service}/{credential-type}) значно спрощує автоматизацію, політики RBAC і робочі процеси ротації в усіх інструментах.
Не пропускайте секретне тестування обертання. Який би інструмент ви не вибрали, запустіть тренування обертання, перш ніж воно вам знадобиться. Переконайтеся, що ваша програма отримує нові облікові дані без простоїв. Динамічні секрети з Vault або ESO значно полегшують це, ніж статичні секрети, оновлені вручну.
Стежте за розповсюдженням таємниць. Із зростанням вашої платформи секрети накопичуються. Інтегруйте звіти про керування секретами в інформаційні панелі розробки платформи. Перегляньте наш посібник із інструментів моніторингу Kubernetes, щоб дізнатися про інструменти спостереження, які можуть відстежувати таємні шаблони доступу.
Який інструмент для якої команди?
Невелика команда, вбудована в хмару (AWS/GCP/Azure): Почніть із зовнішнього секретного оператора, який підключається до рідного секретного сховища вашого хмарного постачальника. Мінімальні операційні витрати, надійна інтеграція аудиту, безкоштовно.
Перша команда GitOps (Argo CD / Flux): Запечатані секрети для збереженої конфігурації GitOps у поєднанні з ESO для конфіденційних облікових даних під час виконання, які не повинні бути в Git навіть зашифрованими.
Підприємство з вимогами відповідності (SOC 2, PCI, HIPAA): HashiCorp Vault — або кластер Raft, що розміщується самостійно, або керований HCP Vault. Журнал аудиту, динамічні облікові дані та детальний механізм політики важко відтворити деінде.
Змішане середовище, орієнтоване на досвід розробника (K8s + локальний + CI/CD): Doppler для уніфікованого DX у різних середовищах або автономне розміщення Infisical, якщо резидентність даних має значення.
Велика команда платформ, що керує мультикластерними середовищами: Зовнішній оператор секретів як рівень абстракції на стороні K8s за підтримки Vault або рідного хмарного сховища. Централізація джерела правди в одному магазині з використанням ESO як універсального адаптера між кластерами є добре перевіреною моделлю у 2026 році.
Пов’язане: Щоб дізнатися про ризики безпеки, створені інструментами кодування штучного інтелекту у ваших маніфестах Kubernetes і конвеєрах CI/CD, перегляньте наш посібник про ризики безпеки кодування vibe у 2026 році.
FAQ
Чи секрети Kubernetes зашифровані за умовчанням?
Ні. Секрети Kubernetes за замовчуванням закодовані на основі base64 — це кодування, а не шифрування. Дані зберігаються в etcd без шифрування, якщо ви явно не ввімкнете Encryption at Rest. Завжди перевіряйте конфігурацію кластера та розглядайте зовнішні засоби керування секретами для виробничих робочих навантажень.
Яка різниця між Sealed Secrets і External Secrets Operator?
Sealed Secrets шифрує секретні маніфести для безпечного зберігання Git — це рішення GitOps. Оператор зовнішніх секретів отримує живі секрети із зовнішніх сховищ (Vault, AWS Secrets Manager тощо) і створює з них власні секрети Kubernetes. Вони вирішують різні проблеми і часто використовуються разом.
Що таке динамічні секрети та чому вони важливі?
Динамічні секрети – це облікові дані, які генеруються на вимогу з автоматичним закінченням терміну дії, а не статичні паролі, які зберігаються безстроково. HashiCorp Vault є основним джерелом динамічних секретів для Kubernetes. Якщо динамічні облікові дані зламано, термін їх дії закінчується за власним розкладом. Це різко обмежує радіус вибуху прориву порівняно з довговічними статичними секретами.
Чи використовувати Doppler або HashiCorp Vault для Kubernetes?
Doppler виграє завдяки досвіду розробників і швидкому засвоєнню. Vault виграє завдяки відповідності вимогам підприємства — динамічним обліковим даним, детальним журналам аудиту та чіткій політиці. Для малих і середніх команд доплерографія часто є швидшим шляхом. Для середовищ SOC 2, PCI DSS або HIPAA Сейф зазвичай є більш обґрунтованим вибором.
Як запобігти витоку секретів у журнали контейнерів?
Монтуйте секрети як файли, а не як змінні середовища (змінні середовища можна відкрити через /proc і кінцеві точки налагодження). Використовуйте драйвер Secrets Store CSI, щоб повністю обійти etcd. Скануйте випадкові таємні коміти у вашому конвеєрі CI/CD за допомогою таких інструментів, як секретний сканер Trivy — див. наш посібник із інструментів сканування вразливостей, щоб дізнатися більше про налаштування.
Який найкращий інструмент керування секретами для невеликої команди Kubernetes?
Почніть із External Secrets Operator, який підтримується рідним секретним сховищем вашого хмарного постачальника. Мінімальні витрати на операції, надійне журналювання аудиту, безкоштовно. Додайте безкоштовний рівень Doppler, якщо вам також потрібен уніфікований досвід розробки/CI/виробничих секретів.
Як інтегрувати AWS Secrets Manager із Kubernetes?
Використовуйте зовнішній оператор секретів із ClusterSecretStore, що вказує на диспетчер секретів AWS. На EKS використовуйте IRSA (ролі IAM для облікових записів служб) для автентифікації IAM на рівні модуля — статичні облікові дані не потрібні. У кластерах, які не належать до EKS, використовуйте користувача IAM із secretsmanager:GetSecretValue, призначеним для ваших конкретних секретних ARN.