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

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

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

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

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

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

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

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

Портал Azure

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

Azure CLI

Команда az ad group create используется для создания групп в идентификаторе Microsoft Entra. Параметры --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. Назначение ролей группе Microsoft Entra

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

Портал Azure

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

Azure CLI

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

az role assignment create --assignee "{appId}" \
    --scope /subscriptions/"{subscriptionName}" \
    --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 и данным для всех учетных записей хранения в группе ресурсов msdocs-sdk-sdk-auth-example, вы назначите субъекту-службе приложения роль участника данных служба хранилища с помощью следующей команды.

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

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

3. Вход в Azure с помощью VS Code, Azure CLI или Azure PowerShell

Azure PowerShell

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

Connect-AzAccount

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

Для проверки подлинности клиентских объектов Пакета SDK Azure в Azure приложение должно использовать DefaultAzureCredential класс из @azure/identity пакета. В этом сценарии последовательно проверка, чтобы узнать, DefaultAzureCredential выполнил ли разработчик вход в Azure с помощью расширения средств VS Code Azure, Azure CLI или Azure PowerShell. Если разработчик вошел в Azure с помощью любого из этих средств, учетные данные, используемые для входа в средство, будут использоваться приложением для проверки подлинности в Azure.

Начните с добавления пакета @azure/удостоверений в приложение.

npm install @azure/identity

Затем для любого кода JavaScript, создающего клиентский объект Пакета SDK Azure в приложении, вам потребуется:

1. DefaultAzureCredential Импортируйте класс из @azure/identity модуля.
2. Создание объекта DefaultAzureCredential.
3. Передайте объект конструктору DefaultAzureCredential клиентского объекта пакета SDK Azure.

Пример этого показан в следующем сегменте кода.

import { BlobServiceClient } from '@azure/storage-blob';
import { DefaultAzureCredential } from '@azure/identity';

// Acquire a credential object
const tokenCredential = DefaultAzureCredential();

const blobServiceClient = BlobServiceClient(
        `https://${accountName}.blob.core.windows.net`,
        tokenCredential
);

DefaultAzureCredential автоматически обнаруживает механизм проверки подлинности, настроенный для приложения, и получает необходимые маркеры для проверки подлинности приложения в Azure. Если приложение использует несколько клиентов ПАКЕТА SDK, то один и тот же объект учетных данных можно использовать с каждым клиентским объектом пакета SDK.