Какие существуют источники для хранения секретов кроме облачных сервисов?

Что проверяют

Знаете ли вы, как секреты попадают в .NET-приложение на каждом этапе: на машине разработчика, в CI и на сервере без облачного хранилища. Следом обычно спрашивают, чем плох пароль в appsettings.json и как устроена ротация.

Как отвечать

Опирайтесь на систему конфигурации .NET: провайдеры читаются по порядку, следующий перекрывает предыдущий. Поэтому секрет подставляется снаружи, а код читает его одинаково через IConfiguration или IOptions<T>.

• User Secrets: команда dotnet user-secrets set, файл secrets.json лежит в профиле пользователя вне репозитория. Подключается только в окружении Development и не шифруется;
• переменные окружения: вложенность через двойное подчёркивание, ConnectionStrings__Default. Стандарт для контейнеров и CI, где их заполняют из секретов пайплайна;
• HashiCorp Vault или OpenBao на своих серверах: аудит, политики доступа, динамические учётные данные для баз с коротким сроком жизни. Из .NET через клиент VaultSharp или через агент, который пишет секреты в файл;
• секреты Kubernetes и Docker: монтируются файлами (у Docker в /run/secrets) и читаются провайдером AddKeyPerFile;
• хранилища ОС: DPAPI через ProtectedData на Windows, Keychain на macOS, с привязкой к машине или пользователю;
• зашифрованные файлы в репозитории: SOPS или git-crypt, ключ расшифровки хранится отдельно.

Отдельно упомяните Data Protection из ASP.NET Core (IDataProtector): она шифрует данные приложения вроде cookie и токенов сброса пароля, но хранилищем секретов конфигурации не является.

Где спотыкаются

Считают User Secrets защищённым хранилищем. Это открытый JSON, который просто лежит вне репозитория.

Называют секрет Kubernetes зашифрованным. По умолчанию это base64 в etcd, шифрование на диске включается отдельно.

Забывают про утечки через логи: исключение с полной строкой подключения или вывод всей конфигурации при старте раскрывают секрет не хуже коммита.