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

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

  • Статья

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

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

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

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

  • Когда разработчик выполняет приложение во время локальной разработки: приложение проходит проверку подлинности в Azure с помощью субъекта-службы приложений для локальной разработки или учетных данных разработчика Azure. Эти параметры рассматриваются в разделе Аутентификация во время локальной разработки.
  • Когда приложение размещено в Azure: приложение проходит проверку подлинности в ресурсах Azure с помощью управляемого удостоверения. Этот параметр рассматривается в разделе Аутентификации в серверных средах.
  • Если приложение размещено и развернуто локально: приложение проходит проверку подлинности в ресурсах Azure с помощью служебной учетной записи приложения. Этот параметр рассматривается в разделе Аутентификация в серверных средах.

DefaultAzureCredential

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

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

Сведения об использовании типа DefaultAzureCredential рассматриваются в разделе «Использование DefaultAzureCredential в приложении».

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

Используйте проверку подлинности на основе маркеров вместо использования строк подключения при создании приложений для Azure. Аутентификация на основе токенов обеспечивает следующие преимущества по сравнению с аутентификацией с использованием строк подключения:

  • Методы проверки подлинности на основе маркеров, описанные в этой статье, позволяют устанавливать определенные разрешения, необходимые приложению в ресурсе Azure. Эта практика следует принципу наименьшего привилегирования. В отличие от этого, строка подключения предоставляет полные права ресурсу Azure.
  • Любой пользователь или любое приложение, имеющее строку подключения, может подключаться к ресурсу Azure. Однако методы аутентификации на основе маркеров ограничивают доступ к ресурсу только для тех приложений, которые предназначены для доступа к этому ресурсу.
  • С управляемым удостоверением не требуется хранить секрет приложения. Приложение является более безопасным, так как нет строки подключения или секрета приложения, которые могут быть скомпрометированы.
  • Пакет azidentity в Azure SDK управляет токенами в фоновом режиме. Управляемые маркеры делают использование аутентификации с использованием маркеров таким же простым, как и использование строки подключения.

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

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

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

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

Например, веб-приложение Gin, развёрнутое в Azure Container Apps, будет назначено управляемое удостоверение. Затем управляемое удостоверение, назначенное приложению, будет использоваться для проверки подлинности приложения в других службах Azure.

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

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

Например, рассмотрим Gin веб-приложение, размещенное на локальных серверах, которое использует Azure Blob Storage. Вы создадите учетную запись службы приложения для приложения с помощью процесса регистрации приложения. AZURE_CLIENT_ID, AZURE_TENANT_IDи AZURE_CLIENT_SECRET будут храниться как переменные среды, которые приложение будет считывать во время выполнения, чтобы предоставить приложению возможность аутентифицироваться в Azure с помощью служебного принципала приложения.

Узнайте о проверке подлинности приложений, размещенных за пределами Azure

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

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

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

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

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

Узнайте об аутентификации с помощью служебных принципов разработчика
Проверка подлинности приложения в Azure с помощью учетных данных разработчика во время локальной разработки. В этом методе разработчик должен войти в Azure из Azure CLI или Azure Developer CLI на локальной рабочей станции. Затем приложение может получить доступ к учетным данным разработчика из хранилища учетных данных и использовать эти учетные данные для доступа к ресурсам Azure из приложения.

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

Узнайте о проверке подлинности с помощью учетных записей разработчиков

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

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

Чтобы использовать DefaultAzureCredential в приложении Go, добавьте пакет azidentity.

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

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

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 CLI, для доступа к набору учетных данных разработчика. Любой подход можно использовать для проверки подлинности приложения в ресурсах Azure во время локальной разработки.

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

Связанное содержимое