Хранение конфигурации ядра asp.net вне вашего источника и ваших конвейеров

Question

Я работаю над основным проектом asp.net и пытаюсь выяснить, как сохранить мой источник и мои конвейеры в секрете на 100%.

У меня есть виртуальная машина, работающая с лазурьюагент и конвейеры Azure Dev для сборки и выпуска. Если я удалю сайт на ВМ, конвейер выпуска автоматически создаст для меня его и развернет последнюю сборку.

Очень круто.

Теперь я ознакомился с рекомендациями по настройкеосновное приложение .Net, и я нашел эту статью: https://www.humankode.com/asp-net-core/asp-net-core-configuration-best-practices-for-keeping-secrets-out-of-source-control

Так что плохая идея хранить секреты в коде, это имеет смысл. Но если я применяю те же принципы безопасности к Yaml, то, конечно же, я не должен размещать секреты в своих конвейерах. Но мне нужны конвейеры, чтобы можно было просто воссоздать сайт с нуля, и он должен просто работать. Каким-то образом сайт должен знать, где находится его sql-соединение по умолчанию, или ему нужен ключ к службе конфигурации приложения Azure. Мне не нужно входить в виртуальную машину и создавать appsettings.json вручную после каждого выпуска!

Так что все, что нужно сайту для работы, должно быть включено в конвейер, поэтому некоторые артефакты или включены вcode.

Я уже несколько дней гуглю, но не могу найти информации о том, как полностью автоматизировать это. Я подумал о создании настраиваемого поставщика конфигурации, который считывает данные из реального реестра виртуальных машин, но это тоже неправильно. Мне в основном нужна опция конфигурации, которая НЕ размещается на самом сайте. Поэтому я настроил его один раз на ВМ и больше никогда.

Answer 1

Подход, который Лекс Ли перечисляет в комментариях, является рекомендуемым Microsoft способом защиты «секретов» в конвейерах.

Ответ Бен Смита, на мой взгляд, такой же хороший, возможно, немного менее безопасный.

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

т.е. соединения дБ преобразуются на этапах разработки, тестирования, UAT и производства.

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

1. Только определенное количество доверенных сотрудников имеют доступ к определениям конвейера выпуска.
2. Даже если кто-то имеет доступ к этим определениям - вы не сможете увидеть защищенную переменную. Даже если вы «открутите замок» на вкладке «Переменная» - вы не сможете увидеть, что это за настройка.

Наши действительные секреты затем хранятся в нашем секретном хранилище предприятия.

Использование хранилища ключей Azure, безусловно, хороший подход. Однако у нас уже есть централизованное место для хранения наших вещей;Я не хочу, чтобы это было в трех местах.

Было бы упущением не включать группы переменных в процесс конвейера. Та же концепция, что и для переменных сборки / выпуска - разница в том, что теперь вы можете поделиться ими в одном месте.

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

Answer 2

Кроме предложений в комментариях к вашим вопросам, вы также можете хранить секреты в разделе «Переменные» конвейера.

Здесь вы можетеМожно добавить переменные, а затем пометить их как секретные, выбрав «Сохранить это значение в секрете». После того, как вы сохранили секрет, его значение затем запутывается, то есть вы можете использовать его, но вы больше не можете видеть его первоначальное значение в рамках Devure в Azure (что по общему признанию может быть довольно разочаровывающим, если вы захотите вернуться к переменной, чтобы проверить ее!).

Затем вы можете ссылаться на секретную переменную в своем конвейере YAML, используя синтаксис:

$(variable-name)

Таким образом, этот подход обеспечивает безопасность секретов в пределах Devure Azure до тех пор, пока они не должны быть разрешены конвейером YAML. сценарий.