Base64 encoding – не шифрование. Kubernetes хранит Secrets в etcd просто в виде base64-кодированной строки, без шифрования по умолчанию. Это сделано для удобства передачи данных, а не для безопасности. Любой, кто вычитает такой секрет, может мгновенно декодировать его содержимое стандартными средствами. Например, если выполнить:

то на выходе получится исходный пароль в открытом виде. Важно понимать: base64 маскирует данные, но не защищает их. Это все равно что спрятать ключ под коврик – для злоумышленника не составит труда его найти.
Доступ с правами к секретам получает слишком многие. По умолчанию Secrets не шифруются при хранении, поэтому каждый, кто имеет доступ к API Kubernetes или напрямую к хранилищу etcd, может прочитать или изменить секрет. Более того, даже без прямого доступа к Secret-объекту есть обходной путь: любая учетная запись, имеющая право создавать Pod в конкретном namespace, способна получить доступ к любому Secret-у в этом namespace. Звучит пугающе, но это подтвержденный факт – Kubernetes допускает, что раз вы можете запускать поды, то можете монтировать в них секреты. Таким образом, разработчик с правами на деплоймент в namespace нередко волей-неволей получает возможность читать все секреты этого namespace, через переменные окружения или том с секретом внутри своего пода).
Пример атаки через Kubernetes-секреты. Допустим, злоумышленник скомпрометировал контейнер приложения, работающего в кластере. Если этот контейнер запущен от сервис-аккаунта с избыточными правами, например, cluster-admin или просто с Role, позволяющей читать секреты, то атакующий сможет эскалировать привилегии – создать новый под и вытащить через него все секреты кластера. Реальные инциденты подтверждают риски: так, одна из утечек произошла у компании WeightWatchers, где из-за незащищенного доступа к кластеру нападающие получили Kubernetes-секреты с AWS-ключами и внутренними паролями. Последствия подобных утечек – от компрометации пользовательских данных до полной компрометации облачной инфраструктуры.
Вывод: Стандартный Kubernetes Secret – это удобный механизм централизованного хранения конфиденциальных данных, но сам по себе он не обеспечивает сильной защиты. Без дополнительных мер, ваши “секреты” в кластере видны практически каждому, кто сумеет к ним дотянуться. Рассмотрим, какие ошибки допускают инженеры при работе с секретами и как этого избежать.

Разработано несколько подходов и инструментов, призванных устранить ограничения штатных Kubernetes Secrets. Рассмотрим самые популярные и эффективные решения:

Sealed Secrets
Sealed Secrets – это open-source инструмент от Bitnami, который решает проблему хранения секретов в Git. Идея проста: секрет зашифровывается на этапе подготовки к коммиту, и в репозиторий отправляется не обычный объект Secret, а специальный объект типа Sealed Secret. В кластере устанавливается контроллер Sealed Secrets, который умеет расшифровывать такие объекты обратно в нормальные Secret-ы. Шифрование асимметричное: при установке контроллер генерирует пару ключей, закрытый хранится внутри кластера, а открытый ключ можно выдать разработчикам. Разработчик шифрует свои секреты локально утилитой kubeseal с использованием публичного ключа и получает YAML манифест Sealed Secret. Этот манифест можно безопасно коммитить в Git – без риска, что данные кто-то прочтет без доступа к кластеру. Когда GitOps-система применяет манифест в кластере, контроллер расшифровывает его своим закрытым ключом и создает обычный Kubernetes Secret, доступный приложению.

Плюсы: Sealed Secrets полностью устраняет проблему хранения секретов в репозитории данные лежат только в зашифрованном виде. Инструмент довольно прост в использовании: контроллер легковесный, не требует сложной настройки и почти не потребляет ресурсов кластера. Разработчики могут самостоятельно шифровать секреты, не имея доступа к закрытому ключу. Это обеспечивает разделение ответственности. В сочетании с корректно настроенным RBAC, Sealed Secrets дает надежное и удобное решение для большинства сценариев хранения конфигурационных данных.
Минусы: хоть Sealed Secrets и защищает покой репозитория, в самом кластере секреты все равно хранятся в обычном виде (base64 в etcd). То есть, злоумышленник, получивший админ-доступ к кластеру, сможет их прочитать – Sealed Secrets здесь уже не поможет. Кроме того, нужно бережно относиться к закрытому ключу контроллера: например, настроить бэкап sealed-secrets-key из namespace kube-system. Потеря этого ключа равносильна потере возможности расшифровать секреты. При восстановлении кластера его нужно будет восстановить из бэкапа, иначе все ранее зашифрованные секреты станут бесполезными. В целом же, при надлежащей эксплуатации минусы сведены к минимуму, и Sealed Secrets часто рекомендуют как первый шаг к безопасному хранению секретов в Kubernetes.

HashiCorp Vault
HashiCorp Vault– это полноценное централизованное хранилище секретов и система управления доступом к ним. Vault обычно разворачивается как отдельный сервис вне Kubernetes или в виде отдельного namespace/подов в кластере. Чем Vault отличается от стандартных секретов? Принципиально всем: Vault не просто сохраняет значения, а шифрует их с помощью мастер-ключа, контролирует доступ через политики (ACL), логирует каждый запрос (audit trail) и позволяет выдавать динамические секреты. Динамические секреты – это учетные данные, которые Vault генерирует на лету по запросу и может автоматически отзывать через заданное время. Например, вместо хранения пароля к базе данных, Vault может при каждом запуске пода выдавать ему временный пароль, действующий сутки, после чего он станет недействительным. Vault поддерживает множество backend-ов: от статических KV-хранилищ до генерации облачных ключей, сертификатов, токенов и т.д. Такая функциональность серьезно повышает уровень безопасности. Даже если секрет утек, он вскоре протухнет, а каждый доступ фиксируется в аудит-логе.

Интеграция с Kubernetes: Vault можно использовать в K8s несколькими способами. Один из популярных –Vault Agent Injector. При деплое приложения injector автоматически подставляет рядом с основным контейнером вспомогательный контейнер Vault Agent, который запрашивает секреты из Vault и кладет их в файл или переменные окружения внутри пода. Приложение читает секрет уже из файла (например, в volume) – таким образом, в Kubernetes Secret ресурс не создается вообще, секрет попадает прямо из Vault в нужный под. Альтернативный способ – использовать External Secrets Operator с backend-ом Vault: тогда оператор сам подтянет данные из Vault и сформирует Kubernetes Secret. Также GitLab CI/CD умеет напрямую вытягивать секреты из Vault во время пайплайна, без сохранения их в репо или variables – за счет OIDC-аутентификации Runner’а в Vault. Argo CD можно интегрировать через плагин argocd-vault-plugin, который на этапе синхронизации манифестов подтянет недостающие значения из Vault и внедрит их перед применением в кластер.
Плюсы: Vault – индустриальный стандарт секретного хранилища. Централизация секретов позволяет управлять ими в одном месте для всех сред и приложений. Vault обеспечивает сильное шифрование (в том числе с использованием аппаратных модулей HSM), гибкую систему доступа, например, можно дать сервису право читать только конкретный ключ, ничего более, и отличные возможности аудита. Он хорошо интегрируется не только с Kubernetes, но и с кучей других систем. Особенно стоит отметить динамические секреты – они устраняют проблему долгоживущих паролей. Например, вместо одного статического пароля к базе, хранящегося годами, каждое приложение получает свой уникальный логин/пароль, который Vault может отозвать в случае компрометации без влияния на других.
Минусы: высокая мощность Vault имеет оборотную сторону – сложность. Развернуть и правильно сконфигурировать Vault – нетривиальная задача; требуются навыки и время. Его нужно масштабировать, мониторить, бэкапить; в случае отказа Vault ваши приложения могут остаться без конфигов. Кроме того, разработчикам нужно обучиться пользоваться Vault API или инструментами вроде Vault Agent. В маленьких компаниях внедрение Vault бывает избыточным по усилиям. Вывод: Vault – мощное решение для крупных проектов с серьезными требованиями (безопасность, комплаенс, аудит), но для небольших команд может быть “пушкой по воробьям”, и тогда на помощь приходят более простые альтернативы.

SOPS и KMS (шифрование в git)
SOPS (Secrets OPerationS) – утилита с открытым исходным кодом от Mozilla, предназначенная для шифрования конфигурационных файлов. Проще говоря, SOPS позволяет шифровать целые YAML/JSON файлы (или отдельные ключи) с помощью заданных ключей шифрования, а при расшифровке возвращать их в исходный формат. Особенность SOPS – поддержка множества источников ключей. Можно шифровать на основе AWS KMS, GCP KMS, Azure Key Vault, локального PGP-ключа, утилиты age и даже через HashiCorp Vault. Например, команда SOPS может зашифровать файл secret.yaml, используя мастер-ключ из AWS KMS, и зафиксировать результат. В репозиторий попадает уже шифрованный YAML. При деплое (например, через CI/CD) файл расшифровывается – конечно, для этого pipeline должен иметь доступ к тому же KMS-ключу или PGP-секретному ключу. SOPS интегрируется с GitOps-инструментами: FluxCD умеет автоматически расшифровывать секреты SOPS при применении манифестов, если предоставить ему ключ; для Argo CD есть плагин, который делает то же самое. Также существует оператор SOPS Secrets Operator, который может в рантайме декодировать SOPS-файлы в соответствующие Secret-ы в кластере.

Плюсы: SOPS довольно прост и не требует поднятия отдельного сервиса. Он хорошо вписывается в существующие процессы — фактически вы работаете с теми же YAML-ами, только зашифрованными. Поддержка облачных KMS позволяет избежать хранения собственных ключей: можно воспользоваться уже имеющимся AWS/GCP-ключом организации для шифрования конфигов. SOPS-файлы можно коммитить в Git – они безопасны, так как взломщику пришлось бы еще получить доступ к вашему KMS или PGP-ключу, чтобы их прочесть. В CI/CD pipeline также легко встраивается расшифровка – многие системы (например, GitLab, GitHub Actions) имеют готовые модули для работы с SOPS или могут запустить sops -d.
Минусы: хотя SOPS устраняет главную боль (хранение в Git), он не решает некоторых других проблем. Секреты все равно попадут в Kubernetes Secrets (то есть дальше – база etcd) в открытую, если вы не используете дополнительные меры шифрования k8s. Вам все так же нужно грамотно настраивать RBAC и аудит – SOPS не контролирует доступ в рантайме. Кроме того, появляется задача управления ключами шифрования: доступ к KMS должен быть строго разграничен, чтобы посторонние не могли дешифровать файлы. В pipeline тоже нельзя случайно выводить расшифрованные секреты в лог. Наконец, SOPS не предоставляет динамических или временных секретов – он оперирует статическими конфигами. В целом, SOPS – отличное решение для малого и среднего масштаба, где Vault избыточен: он закроет вопрос безопасного хранения в репозитории и плавно интегрируется с IaC-процессами.

External Secrets Operator
External Secrets Operator (ESO)– оператор Kubernetes, который синхронизирует секреты из внешних секрет-хранилищ в ваш кластер. Он поддерживает различные источники: HashiCorp Vault, AWS Secrets Manager, Google Secret Manager, Azure Key Vault и др. Архитектура работы такова: вы устанавливаете оператор в кластер и создаете специальный ресурс Secret Store или Cluster Secret Store, в котором прописаны настройки подключения к внешнему хранилищу (например, адрес Vault или AWS, credentials для доступа). Затем для каждого нужного секрета создаете ресурс External Secret, где указываете, какой именно секрет из внешнего хранилища нужно подтянуть и под каким именем сохранить в Kubernetes. Оператор подтягивает данные по API и создает/обновляет обычный Kubernetes Secret в заданном namespace.

Преимущества:

• Сами конфиденциальные данные хранятся вне кластера – в облачном сервисе или Vault, которые изначально предназначены для секретов и обеспечивают их шифрование и контроль доступа. В Git репозитории при этом никаких секретных значений нет – там только манифест External Secret с ссылкой на внешний секрет.
• Оператор умеет следить за обновлениями. Если во внешнем хранилище секрет поменяли, он автоматически обновит и Kubernetes Secret, поддерживая синхронизацию. Это удобно для ротации паролей.
• Поддерживается множество провайдеров и можно подключить сразу несколько SecretStore (например, часть секретов брать из Vault, часть из AWS Secrets Manager – для ESO это штатная ситуация).
• Оператор предоставляет метрики Prometheus для мониторинга состояния синхронизации.

Недостатки:

• External Secrets Operator – это дополнительный компонент, который нужно развернуть и настроить. Интеграция с внешними хранилищами тоже требует управления доступами (например, выдачи AWS IAM роли под этот оператор). На первоначальном этапе внедрение более сложно, чем просто использовать Sealed Secrets или SOPS.
• Хотя секреты и хранятся вне Kubernetes, в кластере они все равно создаются в виде Kubernetes Secret. Это значит, что злоумышленник, получивший доступ к кластеру и namespace, сможет по-прежнему их прочитать. Оператор не решает проблему after the fact – он лишь делает более безопасной доставку.
• Безопасность решения теперь зависит еще и от правильной настройки внешнего хранилища и сетевого доступа к нему. Нужно тщательно выстроить политики в том же Vault/AWS, чтобы гарантировать, что один кластер не сможет вытянуть чужие секреты и т.д.

Когда использовать: External Secrets Operator хорош, когда у вас уже есть внешнее хранилище секретов (Vault или облачный) и вы хотите подключить Kubernetes к этой экосистеме. Он часто применяется в компаниях, где секреты должны храниться централизованно, а Kubernetes – лишь один из потребителей. Благодаря ESO DevOps-инженеры могут не прописывать sensitive-данные нигде в Kubernetes манифестах – достаточно указать ссылки. В крупных командах это повышает безопасность и упрощает управление (правила доступа едины в одном Vault вместо десятков namespace).
Сравнение подходов: Каждый из перечисленных инструментов имеет свою нишу. Ниже – сводная таблица с ключевыми особенностями:

Практические рекомендации
Ниже собраны конкретные советы, которые помогут обезопасить секреты в вашем Kubernetes-кластере. Этот список можно рассматривать как чеклист best practices:

• Включите шифрование etcd (Encryption at Rest). Шифрование секретов «на месте» – штатная возможность Kubernetes, о которой почему-то знают не все. Начиная с версии 1.13 Kubernetes позволяет включить шифрование данных etcd с помощью провайдера KMS. Например, в Amazon EKS можно привязать CMK из AWS KMS: тогда при сохранении секрета API-сервер будет запрашивать шифрование через KMS, и в etcd данные лягут уже зашифрованными. При чтении происходит обратный вызов в KMS для расшифровки. Подобное envelope-шифрование поддерживается и с Google Cloud KMS, Azure Key Vault и другими – или даже с собственным ключом (config file) на уровне API-сервера. Совет: обязательно включайте encryption at rest для Secrets во всех production-кластерах. Это защитит от сценария, когда злоумышленник получил файлы etcd. Без ключа KMS он не сможет вытащить секреты. Учтите, что сам мастер-ключ тоже надо хранить безопасно.
• Ограничьте права доступа к секретам (RBAC). Проведите ревизию ролей и binding-ов в ваших кластерах. Цель – убедиться, что только необходимые сервисы/пользователи имеют доступ к Secret. В идеале никаких cluster-admin у CI/CD pipeline быть не должно. Ищите роли, где в правилах resources: ["secrets"] и убирайте лишнее. Для проверки можно использовать команду: kubectl auth can-i --as <user> --namespace X get secret Y. Это покажет, может ли заданный пользователь читать конкретный секрет. Специальные утилиты, например, rbac-lookup, polaris или встроенные функции Cloud-безопасности, могут упростить обзор RBAC. Не забывайте про service accounts. По умолчанию у них мало прав, но если кто-то привязал SA к роли с секретами – это флаг к устранению. Также отключайте автомонтирование токена automountServiceAccountToken: false для подов, которым не нужен доступ к API. Так вы уменьшите шансы, что злоумышленник воспользуется токеном внутри контейнера.
• Разделите секреты и конфигурацию, используйте разные namespace. Следуйте принципу минимальной видимости. Секреты базы данных продакшена не должны находиться в том же namespace, где работает staging-под. Логически разделяйте окружения и сервисы по namespace и допускайте к ним только нужные приложения. Например, часто создают отдельный namespace (или даже отдельный cluster) для CI/CD pipeline, чтобы он не имел доступа к продакшен-секретам напрямую. Также убедитесь, что секреты не пробрасываются в поды, которым они не требуются. Kubernetes позволяет ограничить видимость секретов для контейнеров в поде. Пользуйтесь этим для микросервисов. Если sidecar не должен знать пароль – не монтируйте ему этот секрет.
• Включите audit-логирование и мониторинг доступа. Настройте audit policy для API-сервера, как упоминалось выше. Логируйте хотя бы события чтения (get) и листинга секретов, а лучше – все обращения к объектам типа Secret. Затем организуйте хранение и анализ этих логов: например, отправляйте их в центральную систему логирования (ELK, Splunk и др.) и настраивайте алерты. Например, если вы обычно не читаете все секреты подряд, то появление серии запросов kubectl get secrets --all-namespaces должно вызвать тревогу. Мониторинг поможет вам спасти ситуацию, если защита дала сбой. Вы не предотвратите чтение секретов, но хотя бы узнаете об этом и сможете принять меры.
• Интегрируйте безопасное хранение секретов в процессы CI/CD. Безопасность не должна “заканчиваться” на этапе написания кода – убедитесь, что ваши конвейеры доставки тоже не раскрывают тайное. Что это значит на практике:
• В системах CI (GitLab CI, Jenkins, GitHub Actions и т.д.) не храните секреты в незашифрованном виде. Используйте специальные механизмы. GitLab CI/CD предлагает защищенные переменные (masked variables) и даже прямую интеграцию с HashiCorp Vault. Воспользуйтесь этим, чтобы пайплайн при запуске подтягивал свежий секрет, а не хранил его статически.
• Если у вас Argo CD или другая GitOps-система, рассмотрите внедрение плагинов для работы с секретами. Например, argocd-vault-plugin или поддержку SOPS. Это позволит хранить секреты шифрованно и расшифровывать их непосредственно перед применением манифестов. По сути, GitOps-подход в сочетании с SOPS/External Secrets избавляет от необходимости кому-либо видеть секреты в явном виде – ни разработчики, ни даже teamlead не увидят пароль, он попадет в кластер уже защищенным способом.
• Для Helm-чартов есть плагин helm-secrets, который автоматизирует шифрование значений. Если вы деплойте через Helm, возьмите за правило: всеValues.yaml, содержащие чувствительные данные, должны быть зашифрованы. А при установке чарта – соответственно расшифрованы, что можно делать на лету в CI.
• Наконец, при сборке контейнеров следите, чтобы в образ не утекли секреты. Часто ошибкой бывает добавление конфигурационных файлов с паролями в Dockerfile. Используйте механизмы build-time секретов (например, флаг--secret в Docker BuildKit) вместо хардкода. И никогда не помещайте секретные значения напрямую в переменные окружения образа по умолчанию.
• Периодически проверяйте уязвимости и обновляйте стратегии. Мир DevOps не стоит на месте. Регулярно появляются новые инструменты и подходы для управлению секретами (CSI-драйверы, SecretStore CRD, улучшения в Kubernetes вроде Secret Manager CSI Driver). Держите руку на пульсе – возможно, ваш стек безопасности стоит обновить. Например, Secrets Store CSI Driver позволяет приложениям монтировать секрет прямо из внешнего хранилища в под, как том, без создания Kubernetes Secret вообще. Это еще более безопасный вариант, хотя и несколько более сложный. Также следите за обновлениями Kubernetes: в новых версиях могут появиться улучшения в управлении секретами. И конечно, обновляйте сам Kubernetes. Патчи безопасности могут закрывать уязвимости, связанные с утечками секретов.

Выводы и чеклист
Защита секретов в Kubernetes – это многослойная задача. Нельзя полагаться лишь на базовые механизмы, думая, что “раз объект называется Secret, значит все надежно”. Мы выяснили, что без дополнительных мер все секреты фактически лежат в открытом виде и доступны тому, кто сумеет их запросить. Чтобы обезопасить продакшн, DevOps-инженеру необходимо действовать проактивно:

• Храните секреты безопасно Не в открытом виде в Git, а шифруйте (Sealed Secrets, SOPS) или выносите во внешние хранилища (Vault, AWS Secrets Manager). Так, чтобы в репозитории и конфигурациях не было нешифрованных паролей.
• Ограничивайте доступ Принцип least privilege обязателен. Никаких широких admin-ролей там, где можно дать read-only. Проверяйте, кто может читать секреты в кластере прямо сейчас.
• Включайте шифрование и аудит Настройте encryption at rest для etcd, чтобы затруднить прямой доступ к секретам в случае компрометации хранилища. Логируйте действия с секретами и анализируйте эти логи.
• Используйте инструменты Берите подходящие вашей команде инструменты управления секретами. Маленькому стартапу, возможно, хватит SOPS и helm-secrets. Большому проекту – стоит внедрить Vault или External Secrets Operator для полной централизации.
• Обучайте команду и автоматизируйте процессы Обеспечьте, чтобы все разработчики знали о рисках (например, почему нельзя коммитить ключи API). Интегрируйте проверки: сканеры репозиториев на секреты (GitGuardian, TruffleHog), пайплайны, прерывающие сборку, если найдена строка, похожая на приватный ключ, и т.д.
• Регулярно проводите ревизии секретов Удаляйте неиспользуемые, меняйте устаревшие, внедрите политику ротации (как минимум для важных ключей). Ключ, который не обновлялся годами, с большой вероятностью уже где-то “засветился”.

Следуя этим рекомендациям, вы существенно снизите риск утечки конфиденциальной информации из вашего Kubernetes-кластера. Kubernetes – мощный инструмент, но ответственность за безопасную эксплуатацию лежит на нас. Проверьте свой текущий стек на соответствие перечисленному чеклисту. Если какие-то пункты не выполнены – самое время ими заняться. Безопасность секретов – тот самый фундамент, который защищает приложение от взлома одним из самых простых способов. Не откладывайте это на потом: возьмите чеклист и улучшите безопасность уже сегодня.

(материал подготовлен для аудитории junior/middle DevOps-инженеров; применяйте полученные знания на практике. Если вы хотите углубиться в тему DevOps/SRE безопасности и получить пошаговые руководства – рассмотрите возможность пройти специализированный курс или воркшоп. Ваши усилия по изучению технологий безопасности окупятся сторицей: ведь защищенный продакшн – это залог спокойствия команды и доверия пользователей.)