Проверка подлинности размещенных в 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.
2. Назначение ролей управляемому удостоверению
Затем определите, какие роли (разрешения) требуется приложению, и назначьте управляемое удостоверение этим ролям в Azure. Управляемое удостоверение можно назначить роли в ресурсе, группе ресурсов или области подписки. В этом примере показано, как назначать роли в области группы ресурсов, так как большинство приложений группируют все ресурсы Azure в одну группу ресурсов.
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
К службам 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
может получать параметры среды и конфигурации управляемых удостоверений для автоматической проверки подлинности в других службах.