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

Статья
06/08/2023

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

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

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

Субъект-служба приложений настраивается для приложения при регистрации приложения в Azure. При регистрации приложений для локальной разработки рекомендуется:

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

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

1. Регистрация приложения в Azure

Объекты субъекта-службы приложений создаются с регистрацией приложения в Azure. Субъекты-службы можно создать с помощью портал Azure или Azure CLI.

Портал Azure
Azure CLI

Войдите на портал Azure и сделайте следующее.

Instructions	Снимок экрана
В портал Azure: Введите регистрации приложений в строке поиска в верхней части портал Azure. Выберите элемент, помеченный Регистрация приложений под заголовком "Службы" в меню, которое отображается под строкой поиска.
На странице Регистрация приложений нажмите кнопку +Создать регистрацию.
На странице регистрации приложения заполните форму следующим образом. Имя → Введите имя регистрации приложения в Azure. Это имя рекомендуется включить имя приложения, имя пользователя, для регистрации приложения и идентификатор, например dev, чтобы указать, что эта регистрация приложения используется в локальной разработке. Поддерживаемые типы учетных записей → учетные записи только в этом каталоге организации. Выберите "Зарегистрировать", чтобы зарегистрировать приложение и создать субъект-службу приложений.
На странице регистрации приложения: Идентификатор приложения (клиента) → Это идентификатор приложения, который приложение будет использовать для доступа к Azure во время локальной разработки. Скопируйте это значение во временное расположение в текстовом редакторе, так как он понадобится в следующем шаге. Идентификатор каталога (клиента) → Это значение также потребуется приложению при проверке подлинности в Azure. Скопируйте это значение во временное расположение в текстовом редакторе, оно также потребуется на следующем шаге. Учетные данные клиента → Необходимо задать учетные данные клиента для приложения, прежде чем приложение сможет пройти проверку подлинности в Azure и использовать службы Azure. Выберите " Добавить сертификат или секрет ", чтобы добавить учетные данные для приложения.
На странице "Сертификаты и секреты" выберите +Создать секрет клиента.
Диалоговое окно "Добавление секрета клиента" появится в правой части страницы. В этом диалоговом окне: Описание → Введите значение Current. Истекает срок действия → Выберите значение 24 месяцев. Нажмите кнопку "Добавить ", чтобы добавить секрет.
На странице "Сертификаты и секреты" отобразится значение секрета клиента. Скопируйте это значение во временное расположение в текстовом редакторе, так как он понадобится в следующем шаге. ВАЖНО. Это единственный раз, когда вы увидите это значение. После выхода или обновления этой страницы вы не сможете снова увидеть это значение. Вы можете добавить дополнительные секреты клиента, не отменив этот секрет клиента, но вы не увидите это значение снова.

Команды Azure CLI могут выполняться в Azure Cloud Shell или на рабочей станции с установленным интерфейсом Azure CLI.

Сначала используйте команду az ad sp create-for-rbac , чтобы создать новый субъект-службу для приложения. При этом создается регистрация приложения для приложения одновременно.

az ad sp create-for-rbac --name {service-principal-name}

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

{
  "appId": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "displayName": "{service-principal-name}",
  "password": "abcdefghijklmnopqrstuvwxyz",
  "tenant": "ffffaaaa-5555-bbbb-6666-cccc7777dddd"
}

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

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

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

Портал Azure
Azure CLI

Instructions	Снимок экрана
Перейдите на страницу идентификатора 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>

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

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

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

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

3. Назначение ролей приложению

Затем необходимо определить, какие роли (разрешения) приложения требуются для ресурсов и назначить эти роли приложению. В этом примере роли назначаются группе Microsoft Entra, созданной на шаге 2. Роли можно назначить роль в ресурсе, группе ресурсов или области подписки. В этом примере показано, как назначать роли в области группы ресурсов, так как большинство приложений группировать все ресурсы 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}" \
    --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

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

4. Задание переменных среды разработки

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

Файл .env никогда не проверяется в системе управления версиями, так как он содержит секретный ключ приложения для Azure. Стандартный файл .gitignore для JavaScript автоматически исключает .env файл из регистрации.

Чтобы использовать dotenv пакет, сначала установите пакет в приложении.

npm install dotenv

Затем создайте файл в корневом .env каталоге приложения. Задайте значения переменной среды со значениями, полученными из процесса регистрации приложения следующим образом:

AZURE_CLIENT_ID → значение идентификатора приложения.
AZURE_TENANT_ID → Значение идентификатора клиента.
AZURE_CLIENT_SECRET → пароль или учетные данные, созданные для приложения.

AZURE_CLIENT_ID=00001111-aaaa-2222-bbbb-3333cccc4444
AZURE_TENANT_ID=ffffaaaa-5555-bbbb-6666-cccc7777dddd
AZURE_CLIENT_SECRET=Aa1Bb~2Cc3.-Dd4Ee5Ff6Gg7Hh8Ii9_Jj0Kk1Ll2

Наконец, в коде запуска приложения используйте dotenv библиотеку для чтения переменных среды из .env файла при запуске.

import 'dotenv/config'

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

Для проверки подлинности клиентских объектов Пакета SDK Azure в Azure приложение должно использовать DefaultAzureCredential класс из @azure/identity пакета. В этом сценарии DefaultAzureCredential обнаруживает переменные среды и AZURE_CLIENT_SECRET считывает эти переменныеAZURE_CLIENT_IDAZURE_TENANT_ID, чтобы получить сведения о субъекте-службе приложения для подключения к Azure.

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

npm install @azure/identity

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

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

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

// Azure authentication dependency
import { DefaultAzureCredential } from '@azure/identity';

// Azure resource management dependency
import { SubscriptionClient } from "@azure/arm-subscriptions";

// Acquire credential
const tokenCredential = new DefaultAzureCredential();

async function listSubscriptions() {
  try {

    // use credential to authenticate with Azure SDKs
    const client = new SubscriptionClient(tokenCredential);

    // get details of each subscription
    for await (const item of client.subscriptions.list()) {
      const subscriptionDetails = await client.subscriptions.get(
        item.subscriptionId
      );
      /* 
        Each item looks like:
      
        {
          id: '/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e',
          subscriptionId: 'aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e',
          displayName: 'YOUR-SUBSCRIPTION-NAME',
          state: 'Enabled',
          subscriptionPolicies: {
            locationPlacementId: 'Internal_2014-09-01',
            quotaId: 'Internal_2014-09-01',
            spendingLimit: 'Off'
          },
          authorizationSource: 'RoleBased'
        },
    */
      console.log(subscriptionDetails);
    }
  } catch (err) {
    console.error(JSON.stringify(err));
  }
}

listSubscriptions()
  .then(() => {
    console.log("done");
  })
  .catch((ex) => {
    console.log(ex);
  });

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

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