Секреты и конфигурация: user-secrets, Vault, переменные окружения

Желательно~3 мин чтенияУровень: senior

Зачем это на собесе

«Где хранить пароли к БД и ключи?» — базовый вопрос по безопасности эксплуатации.

Объяснение

Секрет — пароль, токен, ключ, сертификат. Он не хранится в репозитории, образе Docker, логах и клиентском коде.

Место	Когда
User Secrets (`dotnet user-secrets`)	локальная разработка
Переменные окружения	простые окружения, Docker/Kubernetes (Secret → env)
Kubernetes Secrets (+ шифрование etcd, External Secrets)	кластеры
HashiCorp Vault, Azure Key Vault, AWS Secrets Manager	централизованное хранение, аудит, ротация, динамические секреты
CI/CD-секреты (masked variables)	сборка/деплой

Принципы:

Наименьшие привилегии: у каждого сервиса свои учётные записи с минимальными правами.
Ротация: регулярная смена, возможность быстрого отзыва.
Динамические секреты: Vault выдаёт временные учётные данные БД.
Раздельные окружения: dev/staging/prod с разными секретами.
Аудит доступа.
Сканирование репозитория на утечки (gitleaks, trufflehog, GitHub secret scanning); утёкший секрет считается скомпрометированным — его отзывают, а не только удаляют из истории.

dotnet user-secrets init
dotnet user-secrets set "Jwt:Key" "..."

env:
  - name: ConnectionStrings__Default
    valueFrom: { secretKeyRef: { name: orders-db, key: connection } }

Переменные окружения видны в /proc, docker inspect, дампах и иногда логах старта.
Base64 в Kubernetes Secret — не шифрование.
Секреты в appsettings.json, Dockerfile (ENV, ARG) и истории git.
.env не должен попадать в git (.gitignore).
Для доступа приложения к хранилищу используйте workload identity/IAM-роли, а не ещё один статический секрет.

Что делать, если секрет попал в git?

Считать его скомпрометированным: отозвать и перевыпустить, только потом чистить историю.

Почему Base64 в Kubernetes Secret небезопасен?

Это кодирование, а не шифрование; нужны RBAC и шифрование хранилища.