Почему я должен использовать секреты пользователя только в среде разработки?

Question

Я должен сохранить ключи вне проекта и репозитория. Для этого я хочу использовать Секреты пользователя . Но там написано,

Вызывайте AddUserSecrets только при запуске приложения в среде разработки, как показано в следующем примере

И я не могу понять или найти причину. Почему я не могу использовать его в производственной среде?

Answer 1

Вы можете найти его по предоставленной вами ссылке на документацию по секретам пользователя:

Инструмент Secret Manager не шифрует хранимые секреты и не следует рассматривать как надежный магазин. Это для целей развития только. Ключи и значения хранятся в файле конфигурации JSON в каталог профиля пользователя.

Answer 2

Это инструмент только для разработки. Хранение любого секретного файла в файле сопряжено с риском, поскольку вы можете случайно его зарегистрировать. В производственном процессе вы можете, например, использовать переменные окружения для хранения секретов (или любого другого, более безопасного механизма).

Хотя переменные среды являются одним из наиболее часто используемых вариантов в веб-разработке, есть несколько причин, по которым это может быть не лучшим подходом:

1. Среда неявно доступна для процесса, и трудно отслеживать доступ. В результате, например, вы можете столкнуться с ситуацией, когда ваш отчет об ошибке будет содержать ваши секреты

2. Вся среда передается дочерним процессам (если не отфильтровано явно). Таким образом, ваши секретные ключи неявно становятся доступными для любых сторонних инструментов, которые могут быть использованы.

Все это является одной из причин, по которой такие продукты, как Vault , становятся популярными в наши дни.

Итак, вы можете использовать переменные окружения, но помните.

Answer 3

Я думаю, что короткий ответ заключается в том, что вы, вероятно, могли бы, если бы захотели, но это не то, для чего оно предназначено.

Насколько я понимаю, основная цель секретов пользователей состоит в том, чтобы не допускать учетных данныхуправления источником.Во времена, предшествовавшие GitHub и облаку, большинство разработчиков просто вставляли все учетные данные в web.config, и это было в основном нормально.Тогда многие люди начали использовать общедоступные репозитории и AWS, и внезапно https://www.zdnet.com/article/trufflehog-high-entropy-key-hunter-released-to-the-masses/

В настоящее время существует множество различных инструментов для управления секретами, один из которых лучше всего соответствует вашим потребностям - гораздо более сложный вопрос,но вы могли бы подумать:

• Используете ли вы контролируемый источник контроля доступа?
• Вы работаете в облаке или локально для сборки и развертывания?
• Кто имеет доступ для чтенияк действующим серверам?
• Насколько конфиденциальны данные, которые вы храните?
• Какие другие приложения работают на сервере?

Я просто копался вметод CreateDefaultBuilder и нашел его, что, возможно, имеет значение:

if (hostingEnvironment.IsDevelopment())
{
    Assembly assembly = Assembly.Load(new 
              AssemblyName(hostingEnvironment.ApplicationName));

    if (assembly != (Assembly) null)
          config.AddUserSecrets(assembly, true);
 }

Очевидно, вам не нужно использовать версию по умолчанию, и вы можете добавить секреты для всех сред, но это так.

Answer 4

Секреты пользователя - это, в основном, файл JSOn где-то в вашем каталоге пользователя.Это хорошо работает на вашем ПК разработчика.Но в производственной системе значения, как правило, должны вводиться через более готовые производственные системы конфигурации, такие как Environment Variables, appsettings.json или azure keyvault.Envs и appsettings уже активированы по умолчанию.