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

Статья
10/21/2023

Если приложению необходимо получить доступ к ресурсу Azure (например, служба хранилища, Хранилищу ключей или Cognitive Services), приложение должно пройти проверку подлинности в Azure. Это верно для всех приложений, развернутых в Azure, развернутых локально или в процессе разработки на локальной рабочей станции разработчика. В этой статье описаны рекомендуемые подходы к проверке подлинности приложения в Azure при использовании пакета SDK Azure для JavaScript.

Рекомендуемый подход к проверке подлинности приложений

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

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

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

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

Преимущества проверки подлинности на основе токенов

При создании приложений для Azure настоятельно рекомендуется использовать проверку подлинности на основе маркеров по секретам (строка подключения или ключам). Проверка подлинности на основе токенов предоставляется с помощью DefaultAzureCredential.

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

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

Используйте следующий пакет SDK:

@azure/identity

DefaultAzureCredential

Метод DefaultAzureCredential azure SDK позволяет приложениям использовать различные методы проверки подлинности в зависимости от среды, в которой они выполняются. Это позволяет приложениям развертываться в локальных, тестовых и рабочих средах без изменений кода. Вы настраиваете соответствующий метод проверки подлинности для каждой среды и DefaultAzureCredential автоматически обнаруживает и использует этот метод проверки подлинности. DefaultAzureCredential Использование предпочтительнее использовать условный логику или флаги функций вручную для использования различных методов проверки подлинности в разных средах.

Дополнительные сведения об использовании класса DefaultAzureCredential описаны далее в этой статье в разделе Use DefaultAzureCredential в приложении.

Проверка подлинности в средах сервера

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

Проверка подлинности во время локальной разработки

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

Использование DefaultAzureCredential в приложении

Чтобы использовать DefaultAzureCredential в приложении JavaScript, добавьте пакет @azure/identity в приложение.

npm install @azure/identity

Затем в следующем примере кода показано, как создать экземпляр DefaultAzureCredential объекта и использовать его с клиентским классом Azure SDK, в этом случае blobServiceClient, используемый для доступа к хранилищу BLOB-объектов.

// connect-with-default-azure-credential.js
import { BlobServiceClient } from '@azure/storage-blob';
import { DefaultAzureCredential } from '@azure/identity';
import 'dotenv/config'

const accountName = process.env.AZURE_STORAGE_ACCOUNT_NAME;
if (!accountName) throw Error('Azure Storage accountName not found');

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

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

Последовательность выбора методов проверки подлинности при использовании DefaultAzureCredential

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

Если вы настроили несколько учетных данных, порядок поиска учетных данных в цепочке важен.

Порядок DefaultAzureCredential поиска учетных данных для JavaScript показан на схеме и таблице ниже.

Существует два пути:

Развернутая служба (Azure или локальная среда ): последовательность начинается с переменных среды, а затем управляемого удостоверения, а затем остальные расположения учетных данных (Visual Studio Code, Azure CLI, Azure PowerShell).
Локальная среда разработчика: цепочка локальной рабочей станции разработчика начинается с входа пользователя Visual Studio Code в Azure, показанного в нижней строке интегрированной среды разработки, а затем переходит к Azure CLI, а затем Azure PowerShell. Важно понимать, настроены ли переменные локальной среды для всей среды или виртуальной среды проекта (например, с DOTENV), эти переменные переопределяют цепочку Visual Studio Code —> Azure CLI —> цепочку PowerShell, так как это первые учетные данные, проверка в цепочке.

Тип учетных данных	Description
Среда	DefaultAzureCredential считывает набор переменных среды, чтобы определить, установлен ли субъект-служба приложения (пользователь приложения). В этом случае использует эти значения для `DefaultAzureCredential` проверки подлинности приложения в Azure. Этот метод чаще всего используется в средах сервера, но также может использоваться при разработке локально.
Управляемое удостоверение	Если приложение развернуто на узле Azure с включенным управляемым удостоверением, `DefaultAzureCredential` будет проходить проверку подлинности приложения в Azure с помощью этого управляемого удостоверения. Проверка подлинности с помощью управляемого удостоверения рассматривается в разделе проверки подлинности в средах сервера в этом документе. Этот метод доступен только в том случае, если приложение размещено в Azure с помощью службы с поддержкой управляемого удостоверения.
Visual Studio Code	Если разработчик прошел проверку подлинности в Azure с помощью подключаемого модуля учетной записи Azure Visual Studio Code, `DefaultAzureCredential` будет проходить проверку подлинности приложения в Azure с помощью той же учетной записи.
Azure CLI	Если разработчик прошел проверку подлинности в Azure с помощью `az login` команды в Azure CLI, `DefaultAzureCredential` проверит приложение в Azure с помощью той же учетной записи.
Azure PowerShell	Если разработчик прошел проверку подлинности в Azure с помощью командлета `Connect-AzAccount` Из Azure PowerShell, `DefaultAzureCredential` будет проходить проверку подлинности приложения в Azure с помощью той же учетной записи.
Интерактивный	Если этот параметр включен, DefaultAzureCredential будет интерактивно проходить проверку подлинности разработчика через браузер по умолчанию текущей системы. По умолчанию этот параметр отключен.

Share via