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

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

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

Типы управляемых удостоверений

Существует два типа управляемых удостоверений:

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

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

1. Включение управляемого удостоверения в ресурсе Azure, в котором размещено приложение

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

Вы можете включить управляемое удостоверение для ресурса Azure с помощью портал Azure или Azure CLI.

Портал Azure

Instructions	Снимок экрана
Перейдите к ресурсу, в котором размещен код приложения в портал Azure. Например, можно ввести имя ресурса в поле поиска в верхней части страницы и перейти к нему, выбрав его в диалоговом окне.
На странице ресурса выберите пункт меню "Удостоверение " в меню слева. Все ресурсы Azure, способные поддерживать управляемое удостоверение, будут иметь элемент меню "Удостоверение ", даже если макет меню может немного отличаться.
На странице удостоверений: Измените ползунок состояния на "Вкл.". Выберите Сохранить. Диалоговое окно подтверждения подтвердит, что вы хотите включить управляемое удостоверение для службы. Ответ " Да " и управляемое удостоверение будет включено для ресурса Azure.

Azure CLI

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

Команды Azure CLI, используемые для включения управляемого удостоверения для ресурса Azure, имеют форму az <command-group> identity --resource-group <resource-group-name> --name <resource-name>. Ниже приведены определенные команды для популярных служб Azure.

Служба приложений Azure

az webapp identity assign \
    --resource-group <resource-group-name> \
    --name <web-app-name>

Виртуальные машины Azure

az vm identity assign \
    --resource-group <resource-group-name> \
    --name <virtual-machine-name>

Выходные данные будут выглядеть следующим образом.

{
  "principalId": "99999999-9999-9999-9999-999999999999",
  "tenantId": "33333333-3333-3333-3333-333333333333",
  "type": "SystemAssigned",
  "userAssignedIdentities": null
}

Это principalId значение является уникальным идентификатором управляемого удостоверения. Сохраните копию этих выходных данных, так как эти значения потребуются на следующем шаге.

2. Назначение ролей управляемому удостоверению

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

Портал Azure

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

Azure CLI

Управляемое удостоверение назначается роль в Azure с помощью команды az role assignment create :

az role assignment create \
    --assignee "{managedIdentityId}" \
    --role "{roleName}" \
    --scope "{scope}"

Чтобы получить имена ролей, которым может быть назначен субъект-служба, используйте команду az role definition list :

az role definition list \
    --query "sort_by([].{roleName:roleName, description:description}, &roleName)" \
    --output table

Например, чтобы разрешить управляемому удостоверению идентификатор с идентификатором 99999999-9999-9999-9999-999999999999 ресурса чтения, записи и удаления доступа к служба хранилища Azure контейнерам BLOB-объектов и данным для всех учетных записей хранения в группе ресурсов msdocs-dotnet-sdk-sdk-auth-example, назначьте субъекту-службе приложения роль участника данных blob-объектов хранилища с помощью следующей команды:

az role assignment create \
    --assignee 99999999-9999-9999-9999-999999999999 \
    --role "Storage Blob Data Contributor" \
    --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/msdocs-dotnet-sdk-auth-example"

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

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

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

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

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

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

В выбранном терминале перейдите к каталогу проекта приложения и выполните следующие команды:

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

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

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

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

1. Azure.Identity Включите пространства имен и Microsoft.Extensions.Azure пространства имен с помощью using директив.
2. Зарегистрируйте клиент службы Azure с помощью соответствующего Addметода расширения с префиксом.
3. Передайте экземпляр DefaultAzureCredential UseCredential метода.

Например:

using Microsoft.Extensions.Azure;
using Azure.Identity;

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddBlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"));
    clientBuilder.UseCredential(new DefaultAzureCredential());
});

UseCredential Альтернативой является создание экземпляра DefaultAzureCredential напрямую:

using Azure.Identity;

builder.Services.AddSingleton<BlobServiceClient>(_ =>
    new BlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"),
        new DefaultAzureCredential()));

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

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