Как сохранить учетные данные Azure?

Можете ли вы поделиться небольшим полным примером кода? Как насчет использования DefaultAzureCredentialOptions. Нравиться:

.ConfigureAppConfiguration((context, config) =>
        {
            var appSettings = config.Build();
            var credentialOptions = new DefaultAzureCredentialOptions();
            var credential = new DefaultAzureCredential(credentialOptions);
            config.AddAzureKeyVault(new Uri(appSettings["Url:KeyVault"]), credential);
        })

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

Чтобы настроить его правильно и не ждать 15 секунд при запуске, вы должны настроить DefaultAzureCredentials следующим образом:

        DefaultAzureCredential credentials = new DefaultAzureCredential(new DefaultAzureCredentialOptions
        {
            ExcludeEnvironmentCredential = true,
            ExcludeInteractiveBrowserCredential = true,
            ExcludeAzurePowerShellCredential = true,
            ExcludeSharedTokenCacheCredential = true,
            ExcludeVisualStudioCodeCredential = true,
            ExcludeVisualStudioCredential = true,
            ExcludeAzureCliCredential = true,
            ExcludeManagedIdentityCredential = false,
        });

Исключите все возможности для захвата токена, кроме того, который вы используете, в этом случае «Управляемое удостоверение» или в других случаях AzureCliCredentials.

С уважением.

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

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

Если вы используете DefaultAzureCredential, эти участники смогут использовать проверку подлинности службы Azure в Visual Studio или Visual Studio Code (или EnvironmentCredential), поскольку DefaultAzureCredential будет циклически переключаться между этими различными типами учетных данных, включая VisualStudioCredential и VisualStudioCodeCredential (и EnvironmentCredential) соответственно.

Разработчики могут пройти аутентификацию в своей среде IDE, например. в Visual Studio, перейдя в Tools > Options > Azure Service Authentication, где они могут пройти аутентификацию, используя свои учетные данные Azure.

Предполагая, что их учетным записям AAD был предоставлен доступ к (непроизводственному) экземпляру хранилища ключей, они смогут получить доступ.

Развернутое приложение, предположительно работающее в Azure, будет использовать другой тип учетных данных, например. ManagedIdentityCredential или EnvironmentCredential. Учитывая, что они также обрабатываются DefaultAzureCredential, никаких изменений кода не требуется, чтобы это работало для развернутого экземпляра вашего приложения.

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

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

Для этого типа пользователей, которые просто хотят запустить приложение из терминала, они могут установить некоторые переменные среды, которые будут выбраны EnvironmentCredential (это еще один из типов учетных данных, включенных в DefaultAzureCredential), например. если они запускают приложение в докере, они могут указать переменные среды AZURE_USERNAME и AZURE_PASSWORD (или, альтернативно, AZURE_CLIENT_ID и AZURE_CLIENT_SECRET для большего «машинного» контекста), например. docker run -e AZURE_USERNAME=username -e AZURE_PASSWORD=password ...

Исходя из вашего вопроса, я предполагаю следующее:

• Веб-приложение имеет управляемую идентификацию и имеет разрешения для вашего хранилища ключей.
• Пользователи входят в систему как сами в передней части веб-приложения.

new DefaultAzureCredential(true) просто захватывает текущие учетные данные пользователей. Это будет пользователь переднего плана. Они автоматически кэшируются в соответствии с политикой безопасности вашей организации. Я предполагаю, что это работает правильно.

Частота входа находится вне вашего контроля как разработчика. Проблема, с которой вы столкнулись, связана с организационными параметрами в Azure Active Directory. Ваша частота входа может быть установлена ​​​​одной из следующих:

Требовать повторную аутентификацию каждый раз

Контроль частоты входа каждый раз, когда рискованный пользователь

Чтобы решить вашу проблему, установите частоту входа меньше, чем это, и все будет хорошо. (У меня нет доступа к этому, я бы выложил более качественные фотографии)

Вот ссылка на полную статью о том, как это сделать:

Настройте управление сеансом аутентификации с помощью условного доступа

Это было то, что я искал

https://github.com/Azure/azure-sdk-for-net/issues/23896

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

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