Проверка подлинности приложений .NET в службах Azure во время локальной разработки с помощью учетных записей разработчиков

Статья
08/05/2024

Разработчикам необходимо выполнять отладку и тестирование облачных приложений на локальных рабочих станциях. Когда приложение работает на рабочей станции разработчика во время локальной разработки, оно по-прежнему должно пройти проверку подлинности в любых службах Azure, используемых приложением. В этой статье описывается, как использовать учетные данные разработчика Azure для проверки подлинности приложения в Azure во время локальной разработки.

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

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

Visual Studio
Azure CLI
Azure Developer CLI
Azure PowerShell

Библиотека удостоверений Azure может обнаружить, что разработчик вошел из одного из этих средств. Затем библиотека может получить маркер доступа Microsoft Entra через средство проверки подлинности приложения в Azure в качестве пользователя, выполнившего вход.

Этот подход проще всего настроить для команды разработчиков, так как он использует преимущества существующих учетных записей Azure разработчиков. Однако учетная запись разработчика, скорее всего, имеет больше разрешений, чем требуется для приложения, поэтому превышение разрешений, с которыми приложение выполняется в рабочей среде. В качестве альтернативы можно создать субъекты-службы приложений для использования во время локальной разработки, которые могут быть ограничены только доступом, необходимым для приложения.

1. Создание группы Microsoft Entra для локальной разработки

Так как в приложении почти всегда есть несколько разработчиков, группа Microsoft Entra рекомендуется инкапсулировать роли (разрешения) приложения, необходимые для локальной разработки. Этот подход обеспечивает следующие преимущества:

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

Если у вас есть группа Microsoft Entra для вашей группы разработки, вы можете использовать эту группу. В противном случае выполните следующие действия, чтобы создать группу Microsoft Entra.

Портал Azure
Azure CLI

Instructions	Снимок экрана
Перейдите на страницу идентификатора Microsoft Entra в портал Azure, введя идентификатор Microsoft Entra в поле поиска в верхней части страницы. Выберите идентификатор Microsoft Entra в разделе "Службы ".
На странице идентификатора записи Майкрософт выберите группы в меню слева.
На странице "Все группы" выберите "Создать группу".
На странице "Новая группа": Выберите "Безопасность" в раскрывающемся списке "Тип группы". Имя группы → Имя группы безопасности, которое обычно создается из имени приложения. Также полезно включить строку, например local-dev в имя группы, чтобы указать назначение группы. Описание группы → Описание цели группы. Выберите ссылку "Нет участников", выбранную в разделе "Участники", чтобы добавить участников в группу.
В диалоговом окне "Добавление элементов": Используйте поле поиска для фильтрации списка имен пользователей в списке. Выберите одного или нескольких пользователей для локальной разработки для этого приложения. При выборе объекта объект перемещается в список выбранных элементов в нижней части диалогового окна. По завершении нажмите кнопку "Выбрать ".
Вернитесь на страницу "Создать группу ", выберите "Создать ", чтобы создать группу. Группа будет создана, и вы вернеесь на страницу "Все группы ". Для отображения группы может потребоваться до 30 секунд, и может потребоваться обновить страницу из-за кэширования в портал Azure.

Команда az ad group create используется для создания групп в идентификаторе Microsoft Entra. Параметры --display-name и --mail-nickname являются обязательными. Имя группы должно быть основано на имени приложения. Также полезно включить фразу, например local-dev, в имя группы, чтобы указать назначение группы.

az ad group create \
    --display-name MyDisplay \
    --mail-nickname MyDisplay \
    --description <group-description>

Скопируйте значение id свойства в выходных данных команды. Это id свойство представляет идентификатор объекта группы. Вам потребуется это в последующих шагах. Для получения этого свойства можно также использовать команду az ad group show .

Чтобы добавить участников в группу, вам потребуется идентификатор объекта пользователя Azure. Используйте команду az ad user list для перечисления доступных субъектов-служб. Команда --filter параметра принимает фильтры в стиле OData и может использоваться для фильтрации списка в отображаемом имени пользователя, как показано ниже. Параметр --query ограничивает выходные данные столбцами, интересующими вас.

az ad user list \
    --filter "startswith(displayName, 'Bob')" \
    --query "[].{objectId:id, displayName:displayName}" \
    --output table

Затем команду az ad group member add можно использовать для добавления участников в группу:

az ad group member add \
    --group <group-name> \
    --member-id <object-id>

Примечание.

По умолчанию создание групп Microsoft Entra ограничено определенными привилегированными ролями в каталоге. Если вы не можете создать группу, обратитесь к администратору каталога. Если вы не можете добавить участников в существующую группу, обратитесь к владельцу группы или администратору каталога. Дополнительные сведения см. в статье "Управление группами Microsoft Entra" и членством в группах.

2. Назначение ролей группе Microsoft Entra

Затем определите, какие роли (разрешения) приложению требуются для ресурсов и назначьте эти роли приложению. В этом примере роли назначаются группе Microsoft Entra, созданной на шаге 1. Группы можно назначить роль в ресурсе, группе ресурсов или области подписки. В этом примере показано, как назначать роли в группе ресурсов, области, так как большинство приложений группировать все ресурсы Azure в одну группу ресурсов.

Портал Azure
Azure CLI

Instructions	Снимок экрана
Найдите группу ресурсов для приложения, найдите имя группы ресурсов с помощью поля поиска в верхней части портал Azure. Перейдите к группе ресурсов, выбрав имя группы ресурсов в заголовке "Группы ресурсов" в диалоговом окне.
На странице группы ресурсов выберите элемент управления доступом (IAM) в меню слева.
На странице управления доступом (IAM): Выберите вкладку Назначения ролей. Выберите + Добавить в верхнем меню, а затем выберите Добавить назначение роли в появившемся раскрывающемся меню.
На странице "Добавление назначения ролей" перечислены все роли, которые можно назначить для группы ресурсов. Используйте поле поиска, чтобы отфильтровать список до более управляемого размера. В этом примере показано, как фильтровать роли BLOB-объектов хранилища. Выберите роль, которую вы хотите назначить. Нажмите кнопку "Далее ", чтобы перейти к следующему экрану.
На следующей странице "Добавление назначения ролей" можно указать, какой пользователь назначит роль. Выберите "Пользователь", "Группа" или "Субъект-служба" в разделе "Назначение доступа". Выберите и выберите участников в разделе "Участники". Откроется диалоговое окно справа от портал Azure.
В диалоговом окне выбора элементов: Текстовое поле Select можно использовать для фильтрации списка пользователей и групп в подписке. При необходимости введите первые несколько символов локальной группы Microsoft Entra, созданной для приложения. Выберите локальную группу Microsoft Entra, связанную с приложением. Выберите в нижней части диалогового окна, чтобы продолжить.
Группа Microsoft Entra отображается на экране добавления назначения ролей. Выберите "Рецензирование" и " Назначить" , чтобы перейти на окончательную страницу, а затем проверить и назначить еще раз, чтобы завершить процесс.

Субъект-служба приложений назначается роль в Azure с помощью команды az role assignment create :

az role assignment create \
    --assignee "{appId}" \
    --role "{roleName}" \
    --resource-group "{resourceGroupName}"

Чтобы получить имена ролей, которым может быть назначен субъект-служба, используйте команду az role definition list :

az role definition list \
    --query "sort_by([].{roleName:roleName, description:description}, &roleName)" \
    --output table

Например, чтобы разрешить субъекту-службе приложения с идентификатором приложения 00000000-0000-0000-0000-000000000000 для чтения, записи и удаления доступа к служба хранилища Azure контейнерам BLOB-объектов и данным для всех учетных записей хранения в группе ресурсов msdocs-dotnet-sdk-auth-example, вы назначите субъект-службу приложения роли участника данных BLOB-объектов хранилища с помощью следующей команды:

az role assignment create \
    --assignee "00000000-0000-0000-0000-000000000000" \
    --role "Storage Blob Data Contributor" \
    --resource-group "msdocs-dotnet-sdk-auth-example"

Сведения о назначении разрешений на уровне ресурса или подписки с помощью Azure CLI см. в статье "Назначение ролей Azure с помощью Azure CLI".

Затем войдите в Azure с помощью одного из нескольких средств разработчика. Учетная запись, которую вы выполняете проверку подлинности, также должна существовать в созданной и настроенной ранее группе Microsoft Entra.

Перейдите к параметрам инструментов>, чтобы открыть диалоговое окно параметров.
В поле "Параметры поиска" в верхней части введите Azure, чтобы отфильтровать доступные параметры.
В разделе "Проверка подлинности службы Azure" выберите пункт "Выбор учетной записи".
Выберите раскрывающееся меню в разделе "Выбор учетной записи" и выберите команду "Добавить учетную запись Майкрософт". Откроется окно с запросом на выбор учетной записи. Введите учетные данные для требуемой учетной записи Azure и выберите подтверждение.
Нажмите кнопку "ОК", чтобы закрыть диалоговое окно параметров.

Откройте терминал на рабочей станции разработчика и войдите в Azure из Azure CLI:

az login

Откройте терминал на рабочей станции разработчика и войдите в Azure из Интерфейса командной строки разработчика Azure:

azd auth login

Откройте терминал на рабочей станции разработчика и войдите в Azure из Azure PowerShell:

Connect-AzAccount

4. Реализация DefaultAzureCredential в приложении

DefaultAzureCredential — это упорядоченная последовательность механизмов проверки подлинности в Microsoft Entra. Каждый механизм проверки подлинности является классом, производным от класса TokenCredential, и называется учетными данными. Во время выполнения DefaultAzureCredential пытается пройти проверку подлинности с помощью первых учетных данных. Если эти учетные данные не удается получить маркер доступа, выполняется попытка следующего учетных данных в последовательности и т. д., пока маркер доступа не будет успешно получен. Таким образом, приложение может использовать разные учетные данные в разных средах без написания кода для конкретной среды.

Порядок и расположения, в которых DefaultAzureCredential поиск учетных данных найден в DefaultAzureCredential.

Чтобы использовать DefaultAzureCredential, добавьте Azure.Identity и при необходимости пакеты Microsoft.Extensions.Azure в приложение:

Командная строка
диспетчер пакетов NuGet;

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

dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure

К службам Azure обращаются специализированные клиентские классы из различных клиентских библиотек Azure SDK. Эти классы и собственные пользовательские службы должны быть зарегистрированы, чтобы их можно было получить через внедрение зависимостей во всем приложении. Выполните Program.csследующие действия, чтобы зарегистрировать клиентский класс и DefaultAzureCredential:

Azure.Identity Включите пространства имен и Microsoft.Extensions.Azure пространства имен с помощью using директив.
Зарегистрируйте клиент службы Azure с помощью соответствующего Addметода расширения с префиксом.
Передайте экземпляр DefaultAzureCredential UseCredential метода.

Например:

using Microsoft.Extensions.Azure;
using Azure.Identity;

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddBlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"));
    clientBuilder.UseCredential(new DefaultAzureCredential());
});

UseCredential Альтернативой является создание экземпляра DefaultAzureCredential напрямую:

using Azure.Identity;

builder.Services.AddSingleton<BlobServiceClient>(_ =>
    new BlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"),
        new DefaultAzureCredential()));

Когда предыдущий код выполняется на локальной рабочей станции разработки, он выглядит в переменных среды для субъекта-службы приложений или локально установленных средств разработчика, таких как Visual Studio, для набора учетных данных разработчика. Любой подход можно использовать для проверки подлинности приложения в ресурсах Azure во время локальной разработки.

При развертывании в Azure этот же код также может пройти проверку подлинности приложения в других ресурсах Azure. DefaultAzureCredential может получать параметры среды и конфигурации управляемых удостоверений для автоматической проверки подлинности в других службах.

Поделиться через

Проверка подлинности приложений .NET в службах Azure во время локальной разработки с помощью учетных записей разработчиков

1. Создание группы Microsoft Entra для локальной разработки

2. Назначение ролей группе Microsoft Entra

4. Реализация DefaultAzureCredential в приложении

Дополнительные ресурсы

Поделиться через

Проверка подлинности приложений .NET в службах Azure во время локальной разработки с помощью учетных записей разработчиков

1. Создание группы Microsoft Entra для локальной разработки

2. Назначение ролей группе Microsoft Entra

3. Вход в Azure с помощью средств разработчика

4. Реализация DefaultAzureCredential в приложении

Дополнительные ресурсы