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

Рекомендуемый подход к проверке подлинности Azure приложения для доступа к другим ресурсам Azure — использовать управляемое удостоверение. Этот подход поддерживается для большинства служб Azure, включая приложения, размещенные на Azure App Service, Azure Container Apps и Azure Virtual Machines. Узнайте больше о различных методах проверки подлинности и подходах на странице обзора проверки подлинности . В следующих разделах вы узнаете:

• Основные понятия управляемого удостоверения
• Создание системного управляемого удостоверения для вашего приложения
• Назначение ролей управляемому удостоверению, назначаемого системой
• Проверка подлинности с помощью управляемого удостоверения, назначаемого системой, из кода приложения

Основные понятия управляемого удостоверения

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

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

• System-assigned удостоверения, управляемые системой, активируются непосредственно на ресурсе Azure и связаны с его жизненным циклом. Когда ресурс удаляется, Azure автоматически удаляет удостоверение для вас. Назначаемые системой удостоверения обеспечивают минимальный подход к использованию управляемых удостоверений.
• назначаемые пользователем управляемые удостоверения создаются как автономные ресурсы Azure и обеспечивают большую гибкость и возможности. Они идеально подходят для решений с несколькими Azure ресурсами, которые должны совместно использовать одинаковые удостоверения и разрешения. Например, если нескольким виртуальным машинам требуется доступ к одному набору ресурсов Azure, управляемое удостоверение, назначаемое пользователем, обеспечивает повторное использование и оптимизированное управление.

** В следующих разделах приводятся шаги по включению и использованию управляемого удостоверения, назначенного системой, для размещённого в Azure приложения. Если вам нужно использовать управляемое удостоверение, назначаемое пользователем, посетите статью управляемых удостоверений, назначаемых пользователем для получения дополнительной информации.

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

Чтобы начать использовать системно назначенное управляемое удостоверение с вашим приложением, включите удостоверение на Azure-ресурсе, который размещает ваше приложение, например, Azure App Service, Azure Container Apps или экземпляр Azure Virtual Machines.

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

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

az containerapp identity assign \
    --resource-group <resource-group-name> \
    --name <container-app-name> \
    --system-assigned

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

{
  "principalId": "aaaaaaaa-bbbb-cccc-1111-222222222222",
  "tenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "type": "SystemAssigned",
  "userAssignedIdentities": null
}

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

Затем определите, какие роли необходимы вашему приложению, и назначьте их управляемому удостоверению. Роли можно назначать управляемой идентичности на следующих уровнях:

• Ресурс: назначенные роли применяются только к конкретному ресурсу.
• Группа ресурсов: назначенные роли применяются ко всем ресурсам, содержащимся в группе ресурсов.
• Подписка: назначенные роли применяются ко всем ресурсам, содержащимся в подписке.

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

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

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

az role assignment create \
    --assignee aaaaaaaa-bbbb-cccc-1111-222222222222 \
    --role "Storage Blob Data Contributor" \
    --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/msdocs-sdk-auth-example"

Аутентификация для подключения к службам Azure из вашего приложения

Модуль azidentity предоставляет различные учетные данные — реализации TokenCredential, адаптированные для поддержки различных сценариев и потоков проверки подлинности Microsoft Entra. Так как управляемое удостоверение недоступно при локальном выполнении, следующие шаги демонстрируют, какие учетные данные следует использовать в конкретном сценарии:

• Локальная среда разработки: только во время локальной разработки используйте DefaultAzureCredential для предварительно настроенной цепочки учетных данных. DefaultAzureCredential обнаруживает учетные данные пользователя из локальных средств разработки, таких как Azure CLI. Она также обеспечивает гибкость и удобство повторных попыток, время ожидания ответов и поддержку нескольких вариантов проверки подлинности. Дополнительные сведения см. в статье Аутентификация в службах Azure во время локальной разработки.
• Приложения, размещенные в Azure: Если ваше приложение запущено в Azure, используйте ManagedIdentityCredential для безопасного обнаружения управляемой идентичности, настроенной для вашего приложения. Указание этого точного типа учетных данных предотвращает неожиданное получение других доступных учетных данных.

Реализация кода

Добавьте модуль azidentity.

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

go get github.com/Azure/azure-sdk-for-go/sdk/azidentity

Azure службы доступны с помощью специализированных клиентов из различных клиентских библиотек Azure SDK. Для любого кода Go, создающего экземпляр клиента Azure SDK в приложении, необходимо:

1. Импортируйте пакет azidentity.
2. Создайте экземпляр DefaultAzureCredential типа.
3. Передайте экземпляр типа DefaultAzureCredential конструктору клиента Azure SDK.
4. Задайте переменную среды AZURE_TOKEN_CREDENTIALS равной ManagedIdentityCredential, чтобы убедиться, что DefaultAzureCredential использует только учетные данные управляемой идентификации. Эта практика делает процесс аутентификации более предсказуемым и упрощает отладку при развертывании в Azure. Дополнительные сведения см. в разделе "Использование определенных учетных данных".

Пример этих действий показан в следующем фрагменте кода с клиентом Azure Storage Blob.

import (
	"context"
	"github.com/Azure/azure-sdk-for-go/sdk/azidentity"
	"github.com/Azure/azure-sdk-for-go/sdk/storage/azblob"
)

const (
	account       = "https://<replace_with_your_storage_account_name>.blob.core.windows.net/"
	containerName = "sample-container"
	blobName      = "sample-blob"
	sampleFile    = "path/to/sample/file"
)

func main() {
	// create a credential
	cred, err := azidentity.NewDefaultAzureCredential(nil)
	if err != nil {
	  // TODO: handle error
	}

	// create a client for the specified storage account
	client, err := azblob.NewClient(account, cred, nil)
	if err != nil {
	  // TODO: handle error
	}

	// TODO: perform some action with the azblob Client
	// _, err = client.DownloadFile(context.TODO(), <containerName>, <blobName>, <target_file>, <DownloadFileOptions>)
}

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

Альтернативой DefaultAzureCredential является использование ManagedIdentityCredential. Шаги для использования ManagedIdentityCredential такие же, как для использования типа DefaultAzureCredential.

Пример этих действий показан в следующем фрагменте кода с клиентом Azure Storage Blob.

import (
	"context"
	"github.com/Azure/azure-sdk-for-go/sdk/azidentity"
	"github.com/Azure/azure-sdk-for-go/sdk/storage/azblob"
)

const (
                    // Replace placeholder text with your storage account name
	account       = "https://<replace_with_your_storage_account_name>.blob.core.windows.net/"
	containerName = "sample-container"
	blobName      = "sample-blob"
	sampleFile    = "path/to/sample/file"
)

func main() {
	// create a credential
	cred, err := azidentity.NewManagedIdentityCredential(nil)
	
	// When using User Assigned Managed Identity use this instead and pass your client id in the options
	// clientID := azidentity.ClientID("abcd1234-...")
	// opts := azidentity.ManagedIdentityCredentialOptions{ID: clientID}
	// cred, err := azidentity.NewManagedIdentityCredential(&opts)
	
	if err != nil {
	  // TODO: handle error
	}
	
	// create a client for the specified storage account
	client, err := azblob.NewClient(account, cred, nil)
	if err != nil {
	  // TODO: handle error
	}
	
	// TODO: perform some action with the azblob Client
	// _, err = client.DownloadFile(context.TODO(), <containerName>, <blobName>, <target_file>, <DownloadFileOptions>)
}