Чем Secret принципиально отличается от ConfigMap?

Короткий ответ

Secret предназначен для чувствительных данных (пароли, токены, сертификаты) и по умолчанию хранится в etcd в кодировке base64 (это не шифрование), но Kubernetes ограничивает его отображение в kubectl get и поддерживает шифрование at rest при соответствующей настройке кластера, чего ConfigMap не предусматривает.

Как это работает подробнее

значения Secret кодируются в base64 при хранении в манифесте, но это лишь способ представления бинарных данных в YAML, а не защита — любой, кто имеет доступ к etcd или право на чтение Secret через API, может декодировать значение. Реальная защита обеспечивается RBAC-ограничениями на чтение Secret и опциональным шифрованием etcd at rest (encryption provider).

Пример кода

manifest.yamlКопировать

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  password: cGFzc3dvcmQxMjM=

Что использовать на практике

• Практика. Secret монтируют как файлы или переменные окружения аналогично ConfigMap; для продакшена часто используют внешние системы управления секретами (Vault, облачные Secret Manager) с синхронизацией в Kubernetes Secret через оператор, чтобы не хранить настоящие секреты в Git и получить аудит доступа.

Подводные камни

• Риски. считать base64 шифрованием и хранить реальные пароли в публичном репозитории в виде манифеста Secret; давать широким группам пользователей право get/list на Secret через RBAC; передавать секрет через переменную окружения в случаях, где он может попасть в логи при падении приложения — монтирование файлом безопаснее для части сценариев.