Secret — объект Kubernetes для хранения конфиденциальных данных отдельно от кода приложения и конфигурационных файлов. Паролей баз данных, API-ключей и TLS-сертификатов нет в Docker-образе или Git-репозитории — они передаются в Pod через Secret во время запуска.
Как работает
Secret хранит данные в парах ключ-значение, закодированных в base64. Кодировка base64 — не шифрование; данные могут быть просто декодированы командой echo 'value' | base64 -d. Для реального шифрования используется Encryption at Rest в etcd (настраивается через EncryptionConfiguration) или внешние хранилища: HashiCorp Vault, AWS Secrets Manager.
Два способа использования Secret в Pod:
- Переменная окружения:
env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password. Значение доступно внутри контейнера как$DB_PASSWORD. - Volume (файл): Secret монтируется как файл в директорию. Изменение Secret → автоматическое обновление файла в работающем Pod без перезапуска (с задержкой ~1 минута).
Типы Secret: Opaque (произвольные данные), kubernetes.io/tls (TLS-сертификат и ключ), kubernetes.io/dockerconfigjson (credentials для Docker Registry), kubernetes.io/ssh-auth (SSH-ключ).
История
Secret появились в Kubernetes 1.0 (июль 2015 года) как базовый механизм разделения конфигурации и кода. Проблема незашифрованного хранения в etcd известна с начала: шифрование Secrets at Rest добавлено в Kubernetes 1.7 (2017). External Secrets Operator (интеграция с Vault, AWS SSM) стал де-факто стандартом для production-кластеров после 2020 года.
Secret: безопасное управление в production
Base64-кодирование в Secret не является шифрованием — secrets хранятся в etcd в открытом виде по умолчанию. Для production: включить Encryption at Rest для etcd (EncryptionConfig в kube-apiserver). HashiCorp Vault — внешнее хранилище секретов с динамическими credentials: Vault Injector автоматически монтирует секреты в pod через sidecar-контейнер.
External Secrets Operator (ESO) — синхронизация секретов из AWS Secrets Manager, GCP Secret Manager, Azure Key Vault или HashiCorp Vault в Kubernetes Secrets. Это позволяет хранить секреты вне кластера и ротировать их централизованно. Sealed Secrets (Bitnami) — шифрование Secret через public key, хранение зашифрованного манифеста в Git-репозитории безопасно. GitOps-совместимый подход.
На что обращать внимание
По умолчанию Secrets хранятся в etcd в незашифрованном виде — только base64. Любой, у кого есть доступ к etcd, читает все Secrets кластера. Для production необходимо: включить EncryptionConfiguration или использовать External Secrets Operator + HashiCorp Vault. RBAC (Role-Based Access Control) ограничивает, какие сервисные аккаунты могут читать конкретные Secrets. В K3s шифрование Secrets включается флагом --secret-encryption.
ConfigMap vs Secret: ConfigMap хранит нечувствительные конфигурации (адреса, флаги). Secret — для чувствительных данных. Принципиальная разница в модели доступа и (опциональном) шифровании.
Secret в Kubernetes
Kubernetes Secrets хранятся в etcd в base64-кодировании (не шифровании!) по умолчанию. Для production включите encryption at rest в etcd. Примонтировать Secret как файл: volumeMounts с secretName. Передать как переменную окружения: env.valueFrom.secretKeyRef. Количество Podов, использующих Secret, видно через kubectl describe secret. Внешние системы хранения секретов: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault — интегрируются через CSI-драйверы. На K3s: Secrets работают стандартно, etcd заменён SQLite для single-node. Docker Swarm имеет аналогичный механизм: docker secret create.