Проверка подлинности приложений NET в службах Azure во время локальной разработки с помощью субъектов-служб
При создании облачных приложений разработчикам необходимо выполнять отладку и тестирование приложений на локальной рабочей станции. Когда приложение выполняется на рабочей станции разработчика во время локальной разработки, оно по-прежнему должно пройти проверку подлинности в любых службах Azure, используемых приложением. В этой статье описывается настройка выделенных объектов субъекта-службы приложений для использования во время локальной разработки.
Выделенные субъекты-службы приложений для локальной разработки позволяют следовать принципу наименьших привилегий во время разработки приложений. Так как разрешения ограничены именно тем, что необходимо для приложения во время разработки, код приложения не может случайно получить доступ к ресурсу Azure, предназначенному для использования другим приложением. Это также препятствует возникновению ошибок при перемещении приложения в рабочую среду, так как приложение было перегружено в среде разработки.
Субъект-служба приложений настраивается для приложения при регистрации приложения в Azure. При регистрации приложений для локальной разработки рекомендуется:
- Создайте отдельные регистрации приложений для каждого разработчика, работающего над приложением. Это позволит создать отдельные субъекты-службы приложений для каждого разработчика, которые будут использоваться во время локальной разработки и избежать необходимости совместного использования учетных данных для одного субъекта-службы приложений.
- Создание отдельных регистраций приложений для каждого приложения. Это ограничивает разрешения приложения только тем, что требуется приложению.
Во время локальной разработки переменные среды задаются с удостоверением субъекта-службы приложения. Пакет SDK Azure для NET считывает эти переменные среды и использует эти сведения для проверки подлинности приложения в необходимых ресурсах Azure.
1. Регистрация приложения в Azure
Объекты субъекта-службы приложений создаются с регистрацией приложения в Azure. Это можно сделать с помощью портал Azure или Azure CLI.
Войдите на портал Azure и сделайте следующее.
| Instructions | Снимок экрана |
|---|---|
В портал Azure:
|
|
| На странице Регистрация приложений нажмите кнопку +Создать регистрацию. | 
|
На странице регистрации приложения заполните форму следующим образом.
|
|
На странице регистрации приложения:
|
|
| На странице "Сертификаты и секреты" выберите +Создать секрет клиента. | 
|
Диалоговое окно "Добавление секрета клиента" появится в правой части страницы. В этом диалоговом окне:
|
|
| На странице "Сертификаты и секреты" отобразится значение секрета клиента. Скопируйте это значение во временное расположение в текстовом редакторе, так как он понадобится на следующем шаге. ВАЖНО. Это единственный раз, когда вы увидите это значение. После выхода или обновления этой страницы вы не сможете снова увидеть это значение. Вы можете добавить дополнительный секрет клиента без недопустимого этого секрета клиента, но вы не увидите это значение снова. |
|
2. Создание группы безопасности Azure AD для локальной разработки
Так как обычно существует несколько разработчиков, работающих над приложением, рекомендуется создать группу Azure AD, чтобы инкапсулировать роли (разрешения), необходимые приложению в локальной разработке, а не назначать роли отдельным объектам субъекта-службы. Это дает следующие преимущества.
- Каждый разработчик гарантирует, что на уровне группы назначены одни и те же роли, так как роли назначаются на уровне группы.
- Если для приложения требуется новая роль, ее необходимо добавить только в группу Azure AD для приложения.
- Если новый разработчик присоединяется к команде, для разработчика создается новый субъект-служба приложений и добавляется в группу, гарантируя, что разработчик имеет правильные разрешения на работу с приложением.
| Instructions | Снимок экрана |
|---|---|
| Перейдите на страницу Azure Active Directory в портал Azure, введя Azure Active Directory в поле поиска в верхней части страницы, а затем выберите Azure Active Directory из списка служб. | 
|
| На странице Azure Active Directory выберите группы в меню слева. | 
|
| На странице "Все группы" выберите "Создать группу". | 
|
На странице "Новая группа":
|
|
В диалоговом окне "Добавление элементов":
|
|
| Вернитесь на страницу "Создать группу ", выберите "Создать ", чтобы создать группу. Группа будет создана, и вы вернеесь на страницу "Все группы ". Для отображения группы может потребоваться до 30 секунд, и может потребоваться обновить страницу из-за кэширования в портал Azure. |
|
3. Назначение ролей приложению
Затем необходимо определить, какие роли (разрешения) приложения требуются для ресурсов и назначить эти роли приложению. В этом примере роли будут назначены группе Azure Active Directory, созданной на шаге 2. Роли можно назначить роль в ресурсе, группе ресурсов или области подписки. В этом примере показано, как назначать роли в области группы ресурсов, так как большинство приложений группируют все ресурсы Azure в одну группу ресурсов.
| Instructions | Снимок экрана |
|---|---|
| Найдите группу ресурсов для приложения, найдите имя группы ресурсов с помощью поля поиска в верхней части портал Azure. Перейдите к группе ресурсов, выбрав имя группы ресурсов в заголовке "Группы ресурсов" в диалоговом окне. |
|
| На странице группы ресурсов выберите элемент управления доступом (IAM) в меню слева. | 
|
На странице управления доступом (IAM):
|
|
На странице "Добавление назначения ролей" перечислены все роли, которые можно назначить для группы ресурсов.
|
|
На следующей странице "Добавление назначения ролей" можно указать, какой пользователь назначит роль.
|
|
В диалоговом окне выбора элементов:
|
|
| Теперь группа Azure AD будет отображаться как выбранная на экране добавления назначения ролей. Выберите "Рецензирование" и " Назначить" , чтобы перейти на окончательную страницу, а затем проверить и назначить еще раз, чтобы завершить процесс. |
|
4. Задание переменных среды приложения
Объект DefaultAzureCredential будет искать сведения субъекта-службы в наборе переменных среды во время выполнения. Существует несколько способов настройки переменных среды при работе с .NET в зависимости от инструментов и среды.
Независимо от выбранного подхода необходимо настроить следующие переменные среды при работе с субъектом-службой.
AZURE_CLIENT_ID→ значение идентификатора приложения.AZURE_TENANT_ID→ Значение идентификатора клиента.AZURE_CLIENT_SECRET→ пароль или учетные данные, созданные для приложения.
При локальной работе с Visual Studio переменные среды можно задать в launchsettings.json файле в папке Properties проекта. При запуске приложения эти значения будут автоматически извлечены. Помните, что эти конфигурации не перемещаются вместе с приложением при его развертывании, поэтому вам по-прежнему потребуется настроить переменные среды в целевой среде размещения.
"profiles": {
"SampleProject": {
"commandName": "Project",
"dotnetRunMessages": true,
"launchBrowser": true,
"applicationUrl": "https://localhost:7177;http://localhost:5177",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development",
"AZURE_CLIENT_ID": "00000000-0000-0000-0000-000000000000",
"AZURE_TENANT_ID":"11111111-1111-1111-1111-111111111111",
"AZURE_CLIENT_SECRET": "=abcdefghijklmnopqrstuvwxyz"
}
},
"IIS Express": {
"commandName": "IISExpress",
"launchBrowser": true,
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development",
"AZURE_CLIENT_ID": "00000000-0000-0000-0000-000000000000",
"AZURE_TENANT_ID": "11111111-1111-1111-1111-111111111111",
"AZURE_CLIENT_SECRET": "=abcdefghijklmnopqrstuvwxyz"
}
}
}
5. Реализация DefaultAzureCredential в приложении
DefaultAzureCredential поддерживает несколько методов проверки подлинности и определяет метод проверки подлинности, используемый во время выполнения. Таким образом, приложение может использовать различные методы проверки подлинности в разных средах без реализации конкретного кода среды.
Порядок и расположения, в которых DefaultAzureCredential поиск учетных данных найден в DefaultAzureCredential.
Чтобы реализовать DefaultAzureCredential, сначала добавьте Azure.Identity в приложение пакеты и при необходимости Microsoft.Extensions.Azure . Это можно сделать с помощью командной строки или диспетчер пакетов NuGet.
Откройте среду терминала в каталоге проекта приложения и введите следующую команду.
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure
Службы Azure обычно обращаются с помощью соответствующих клиентских классов из пакета SDK. Эти классы и собственные пользовательские службы должны быть зарегистрированы в файле, чтобы их можно было получить с помощью внедрения зависимостей во Program.cs всем приложении. В ней Program.csвыполните приведенные ниже действия, чтобы правильно настроить службу и DefaultAzureCredential.
Azure.IdentityВключите пространства имен иMicrosoft.Extensions.Azureпространства имен с директивойusing.- Зарегистрируйте службу Azure с помощью соответствующих вспомогательных методов.
- Передайте экземпляр
DefaultAzureCredentialобъекта методуUseCredential.
Пример этого показан в следующем сегменте кода.
using Microsoft.Extensions.Azure;
using Azure.Identity;
// Inside of Program.cs
builder.Services.AddAzureClients(x =>
{
x.AddBlobServiceClient(new Uri("https://<account-name>.blob.core.windows.net"));
x.UseCredential(new DefaultAzureCredential());
});
Кроме того, вы также можете использовать DefaultAzureCredential службы напрямую без помощи дополнительных методов регистрации Azure, как показано ниже.
using Azure.Identity;
// Inside of Program.cs
builder.Services.AddSingleton<BlobServiceClient>(x =>
new BlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"),
new DefaultAzureCredential()));
При запуске приведенного выше кода на локальной рабочей станции во время локальной разработки он будет выглядеть в переменных среды для субъекта-службы приложений или в Visual Studio, VS Code, Azure CLI или Azure PowerShell для набора учетных данных разработчика, который можно использовать для проверки подлинности приложения в ресурсах Azure во время локальной разработки.
При развертывании в Azure этот же код также может пройти проверку подлинности приложения в других ресурсах Azure. DefaultAzureCredential может получать параметры среды и конфигурации управляемых удостоверений для автоматической проверки подлинности в других службах.
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по