Проверка подлинности приложений 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.
Перейдите на страницу идентификатора Microsoft Entra в портал Azure, введя идентификатор Microsoft Entra в поле поиска в верхней части страницы, а затем выберите идентификатор Microsoft Entra из служб.
На странице идентификатора записи Майкрософт выберите группы в меню слева.
На странице "Все группы" выберите "Создать группу".
На странице "Новая группа":
Тип группы → Security.
Имя группы → Имя группы безопасности, которое обычно создается из имени приложения. Также полезно включить строку, например local-dev в имя группы, чтобы указать назначение группы.
Описание группы → Описание цели группы.
Выберите ссылку "Нет участников", выбранную в разделе "Участники", чтобы добавить участников в группу.
В диалоговом окне "Добавление элементов":
Используйте поле поиска для фильтрации списка имен пользователей в списке.
Выберите одного или нескольких пользователей для локальной разработки для этого приложения. При выборе объекта объект перемещается в список выбранных элементов в нижней части диалогового окна.
По завершении нажмите кнопку "Выбрать ".
Вернитесь на страницу "Создать группу ", выберите "Создать ", чтобы создать группу.
Группа будет создана, и вы вернеесь на страницу "Все группы ". Для отображения группы может потребоваться до 30 секунд, и может потребоваться обновить страницу из-за кэширования в портал Azure.
Команда 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 \
--group <group-name> \
--member-id <object-id>
2. Назначение ролей группе Microsoft Entra
Затем необходимо определить, какие роли (разрешения) приложения требуются для ресурсов и назначить эти роли приложению. В этом примере роли назначаются группе Microsoft Entra, созданной на шаге 1. Роли можно назначить роль в ресурсе, группе ресурсов или области подписки. В этом примере показано, как назначать роли в области группы ресурсов, так как большинство приложений группировать все ресурсы Azure в одну группу ресурсов.
Найдите группу ресурсов для приложения, найдите имя группы ресурсов с помощью поля поиска в верхней части портал Azure.
Перейдите к группе ресурсов, выбрав имя группы ресурсов в заголовке "Группы ресурсов" в диалоговом окне.
На странице группы ресурсов выберите элемент управления доступом (IAM) в меню слева.
На странице управления доступом (IAM):
Выберите вкладку Назначения ролей.
Выберите + Добавить в верхнем меню, а затем выберите Добавить назначение роли в появившемся раскрывающемся меню.
На странице "Добавление назначения ролей" перечислены все роли, которые можно назначить для группы ресурсов.
Используйте поле поиска, чтобы отфильтровать список до более управляемого размера. В этом примере показано, как фильтровать роли BLOB-объектов хранилища.
Выберите роль, которую вы хотите назначить.
Нажмите кнопку "Далее ", чтобы перейти к следующему экрану.
На следующей странице "Добавление назначения ролей" можно указать, какой пользователь назначит роль.
Выберите "Пользователь", "Группа" или "Субъект-служба" в разделе "Назначение доступа".
Выбор и выбор элементов в разделе "Элементы"
Откроется диалоговое окно справа от портал Azure.
В диалоговом окне выбора элементов:
Текстовое поле Select можно использовать для фильтрации списка пользователей и групп в подписке. При необходимости введите первые несколько символов локальной группы Microsoft Entra, созданной для приложения.
Выберите локальную группу Microsoft Entra, связанную с приложением.
Выберите в нижней части диалогового окна, чтобы продолжить.
Группа Microsoft Entra отображается на экране добавления назначения ролей.
Выберите "Рецензирование" и " Назначить" , чтобы перейти на окончательную страницу, а затем проверить и назначить еще раз, чтобы завершить процесс.
az role definition list --query "sort_by([].{roleName:roleName, description:description}, &roleName)" --output table
Например, чтобы разрешить субъекту-службе приложений читать, записывать и удалять доступ к служба хранилища Azure контейнерам BLOB-объектов и данным для всех учетных записей хранения в группе ресурсов msdocs-sdk-auth-example, необходимо назначить субъект-службу приложения роли участника данных BLOB-объектов хранилища, выполнив следующую команду.
az role assignment create --assignee "aaaaaaaa-bbbb-cccc-7777-888888888888" \
--scope /subscriptions/"Storage Blob Data Subscriber" \
--role "Storage Blob Data Contributor" \
--resource-group "msdocs-sdk-auth-example"
Откройте терминал на рабочей станции разработчика и войдите в Azure из Azure PowerShell.
Connect-AzAccount
4. Реализация DefaultAzureCredential в приложении
Для проверки подлинности клиентских объектов Пакета SDK Azure в Azure приложение должно использовать DefaultAzureCredential класс из @azure/identity пакета. В этом сценарии последовательно проверяет, DefaultAzureCredential выполнил ли разработчик вход в Azure с помощью расширения средств VS Code Azure, Azure CLI или Azure PowerShell. Если разработчик вошел в Azure с помощью любого из этих средств, учетные данные, используемые для входа в средство, будут использоваться приложением для проверки подлинности в Azure.
Затем для любого кода JavaScript, создающего клиентский объект Пакета SDK Azure в приложении, вам потребуется:
DefaultAzureCredential Импортируйте класс из @azure/identity модуля.
Создание объекта DefaultAzureCredential.
Передайте объект конструктору 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.