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

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

Чтобы приложение выполнялось проверку подлинности в Azure во время локальной разработки с помощью учетных данных Azure разработчика, разработчик должен войти в Azure из расширения средств VS Code Azure, Azure CLI или Azure PowerShell. Пакет SDK Azure для .NET может обнаружить, что разработчик вошел в систему из одного из этих средств, а затем получите необходимые учетные данные из кэша учетных данных для проверки подлинности приложения в Azure в качестве пользователя, вошедшего в систему.

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

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

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

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

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

Портал Azure

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

Azure CLI

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

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

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

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

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

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

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

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

Портал Azure

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

Azure CLI

Субъект-служба приложений назначается роль в 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

Например, чтобы разрешить субъекту-службе приложения с помощью appId 00000000-0000-0000-0000-000000000000 для чтения, записи и удаления доступа к служба хранилища Azure контейнерам BLOB-объектов и данным для всех учетных записей хранения в группе ресурсов msdocs-dotnet-sdk-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".

3. Вход в Azure с помощью средств .NET

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

Visual Studio

В верхнем меню Visual Studio перейдите к меню "Параметры инструментов>", чтобы открыть диалоговое окно параметров. В строке поиска в левом верхнем углу введите Azure , чтобы отфильтровать параметры. В разделе "Проверка подлинности службы Azure" выберите пункт "Выбор учетной записи".

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

Расширение средств VS Code Azure

Чтобы приложение использовало учетные данные разработчика из VS Code, расширение средств Azure VS Code должно быть установлено в VS Code.

Установка расширений средств Azure для VS Code

На левой панели появится значок Azure. Выберите этот значок, после чего отобразится панель управления для служб Azure. Выберите Войти в Azure в любой службе, чтобы завершить процесс проверки подлинности средств Azure в Visual Studio Code.

Azure CLI

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

az login

Azure PowerShell

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

Connect-AzAccount

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

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

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

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

Командная строка

Откройте среду терминала в каталоге проекта приложения и введите следующую команду.

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

диспетчер пакетов NuGet

Щелкните правой кнопкой мыши узел проекта в Visual Studio и выберите пункт "Управление пакетами NuGet". Найдите Azure.Identity в поле поиска и установите соответствующий пакет. Повторите этот процесс для пакета Microsoft.Extensions.Azure , а также.

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

1. Azure.Identity Включите пространства имен и Microsoft.Extensions.Azure пространства имен с директивойusing.
2. Зарегистрируйте службу Azure с помощью соответствующих вспомогательных методов.
3. Передайте экземпляр 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 может получать параметры среды и конфигурации управляемых удостоверений для автоматической проверки подлинности в других службах.