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

Статья
08/02/2024

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

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

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

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

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

Во время локальной разработки переменные среды задаются с удостоверением субъекта-службы приложения. Библиотека удостоверений Azure считывает эти переменные среды и использует эти сведения для проверки подлинности приложения в необходимых ресурсах 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": "00000000-0000-0000-0000-000000000000",
  "displayName": "{service-principal-name}",
  "password": "abcdefghijklmnopqrstuvwxyz",
  "tenant": "11111111-1111-1111-1111-111111111111"
}

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

2. Создание группы 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 и --mail-nickname являются обязательными. Имя, заданное группе, должно быть основано на имени приложения. Также полезно включить фразу, например local-dev, в имя группы, чтобы указать назначение группы.

az ad group create \
    --display-name MyDisplay \
    --mail-nickname MyDisplay \
    --description {group-description}

Чтобы добавить участников в группу, требуется идентификатор объекта субъекта-службы приложения, который отличается от идентификатора приложения. Используйте команду az ad sp list для перечисления доступных субъектов-служб. Команда --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}" \
    --role "{roleName}" \
    --resource-group "{resourceGroupName}"

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

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

Например, чтобы разрешить субъекту-службе приложения доступ к контейнерам больших двоичных объектов и данным служба хранилища Azure appId 00000000-0000-0000-0000-000000000000 контейнерам BLOB-объектов и данным в группе ресурсов msdocs-dotnet-sdk-sdk-auth, назначьте субъекту-службе приложений роль участника данных хранилища с помощью следующей команды:

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

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

4. Задание переменных среды приложения

Во время выполнения DefaultAzureCredential ищет сведения субъекта-службы в коллекции переменных среды. Существует несколько способов настройки переменных среды при работе с .NET в зависимости от инструментов и среды.

Независимо от выбранного подхода настройте следующие переменные среды при работе с субъектом-службой:

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

При локальной работе с Visual Studio переменные среды можно задать в launchsettings.json файле в папке Properties проекта. При запуске приложения эти значения автоматически извлекаются. Имейте в виду, что эти конфигурации не перемещаются вместе с приложением при его развертывании, поэтому необходимо настроить переменные среды в целевой среде размещения.

"profiles": {
    "SampleProject": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "applicationUrl": "https://localhost:7177;http://localhost:5177",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development",
        "AZURE_CLIENT_ID": "00000000-0000-0000-0000-000000000000",
        "AZURE_TENANT_ID":"11111111-1111-1111-1111-111111111111",
        "AZURE_CLIENT_SECRET": "=abcdefghijklmnopqrstuvwxyz"
      }
    },
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development",
        "AZURE_CLIENT_ID": "00000000-0000-0000-0000-000000000000",
        "AZURE_TENANT_ID": "11111111-1111-1111-1111-111111111111",
        "AZURE_CLIENT_SECRET": "=abcdefghijklmnopqrstuvwxyz"
      }
    }
  }

При локальной работе с Visual Studio Code переменные среды можно задать в launch.json файле проекта. При запуске приложения эти значения будут автоматически извлечены. Имейте в виду, что эти конфигурации не перемещаются вместе с приложением при его развертывании, поэтому необходимо настроить переменные среды в целевой среде размещения.

"configurations": [
{
    "env": {
        "ASPNETCORE_ENVIRONMENT": "Development",
        "AZURE_CLIENT_ID": "00000000-0000-0000-0000-000000000000",
        "AZURE_TENANT_ID":"11111111-1111-1111-1111-111111111111",
        "AZURE_CLIENT_SECRET": "=abcdefghijklmnopqrstuvwxyz"
    }
}

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

# Set user environment variables
setx ASPNETCORE_ENVIRONMENT "Development"
setx AZURE_CLIENT_ID "00000000-0000-0000-0000-000000000000"
setx AZURE_TENANT_ID "11111111-1111-1111-1111-111111111111"
setx AZURE_CLIENT_SECRET "=abcdefghijklmnopqrstuvwxyz"

# Set system environment variables - requires running as admin
setx ASPNETCORE_ENVIRONMENT "Development"
setx AZURE_CLIENT_ID "00000000-0000-0000-0000-000000000000" /m
setx AZURE_TENANT_ID "11111111-1111-1111-1111-111111111111" /m
setx AZURE_CLIENT_SECRET "=abcdefghijklmnopqrstuvwxyz" /m

PowerShell также можно использовать для задания переменных среды на уровне пользователя или компьютера:

# Set user environment variables
[Environment]::SetEnvironmentVariable("ASPNETCORE_ENVIRONMENT", "Development", "User")
[Environment]::SetEnvironmentVariable("AZURE_CLIENT_ID", "00000000-0000-0000-0000-000000000000", "User")
[Environment]::SetEnvironmentVariable("AZURE_TENANT_ID", "11111111-1111-1111-1111-111111111111", "User")
[Environment]::SetEnvironmentVariable("AZURE_CLIENT_SECRET", "=abcdefghijklmnopqrstuvwxyz", "User")

# Set system environment variables - requires running as admin
[Environment]::SetEnvironmentVariable("ASPNETCORE_ENVIRONMENT", "Development", "Machine")
[Environment]::SetEnvironmentVariable("AZURE_CLIENT_ID", "00000000-0000-0000-0000-000000000000", "Machine")
[Environment]::SetEnvironmentVariable("AZURE_TENANT_ID", "11111111-1111-1111-1111-111111111111", "Machine")
[Environment]::SetEnvironmentVariable("AZURE_CLIENT_SECRET", "=abcdefghijklmnopqrstuvwxyz", "Machine")

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

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

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

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

Командная строка
диспетчер пакетов NuGet;

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

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

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

Azure.Identity Включите пространства имен и Microsoft.Extensions.Azure пространства имен с помощью using директив.
Зарегистрируйте клиент службы Azure с помощью соответствующего Addметода расширения с префиксом.
Передайте экземпляр 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 может получать параметры среды и конфигурации управляемых удостоверений для автоматической проверки подлинности в других службах.

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