Цепочки учетных данных в клиентской библиотеке удостоверений Azure для Go

Клиентская библиотека удостоверений Azure предоставляет учетные данные— общедоступные типы, реализующие интерфейс TokenCredential библиотеки Azure Core. Учетные данные представляют собой отдельный процесс аутентификации для получения токена доступа из Microsoft Entra ID. Эти учетные данные можно объединить в цепочку, чтобы сформировать упорядоченную последовательность механизмов проверки подлинности, которые необходимо предпринять.

Как работает цепочка учетных данных

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

Почему стоит использовать цепочки учетных данных

Учетные данные, связанные с цепочкой, могут предложить следующие преимущества:

• Осведомленность о среде: Автоматически выбирает наиболее подходящие учетные данные в зависимости от среды, в которой работает приложение. Без этого вам потребуется написать код следующим образом:

  // Set up credential based on environment (Azure or local development)
  if os.Getenv("WEBSITE_HOSTNAME") != "" {
      clientID := azidentity.ClientID("abcd1234-...")
      opts := azidentity.ManagedIdentityCredentialOptions{ID: clientID}
      cred, err := azidentity.NewManagedIdentityCredential(&opts)
  
      if err != nil {
        // TODO: handle error
      }
  }
  else {
      // Use Azure CLI Credential
      credential, err = azidentity.NewAzureCLICredential(nil)
  
      if err != nil {
        // TODO: handle error
      }
  }
  

• Плавный переход: Ваше приложение может перейти от локальной разработки к тестовой или рабочей среде без изменения кода аутентификации.

• Улучшенная устойчивость: Включает резервный механизм, который переходит к следующим учетным данным, когда предыдущее не удается получить токен доступа.

Выбор связанных учетных данных

При использовании Go существует два варианта цепочки авторизации.

• Использовать предварительно настроенную цепочку: используйте предварительно настроенную цепочку, реализованную типом DefaultAzureCredential. Для этого подхода ознакомьтесь с разделом DefaultAzureCredential.
• создать настраиваемую цепочку учетных данных: начните с пустой цепочки и включите только то, что вам нужно. Для получения информации об этом подходе см. раздел Обзор ChainedTokenCredential.

Обзор DefaultAzureCredential

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

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

Заказ	Мандат	Описание
1	Окружающая среда	Считывает коллекцию переменных среды , чтобы определить, настроен ли субъект-служба приложения (пользователь приложения). В этом случае DefaultAzureCredential использует эти значения для проверки подлинности приложения в Azure. Этот метод чаще всего используется в средах сервера, но также может использоваться при разработке локально.
2	Идентификатор рабочей нагрузки	Если приложение развернуто на узле Azure с включенной функцией удостоверения рабочей нагрузки, аутентифицируйте эту учетную запись.
3	Управляемая идентификация	Если приложение развернуто на узле Azure с включенным управляемым удостоверением, выполните проверку подлинности приложения в Azure с помощью этого управляемого удостоверения.
4	Azure CLI	Если разработчик прошел проверку подлинности в Azure с помощью az login команды Azure CLI, выполните проверку подлинности приложения в Azure с помощью той же учетной записи.
5	Azure Developer CLI	Если разработчик прошел проверку подлинности в Azure с помощью команды azd auth login Azure Developer CLI, выполните проверку подлинности с помощью этой учетной записи.

В самой простой форме можно использовать версию без параметров DefaultAzureCredential следующим образом:

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

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

// create a Blob service client 
accountURL := "https://<my_account_name>.blob.core.windows.net"
client, err := azblob.NewClient(accountURL, credential, nil)
if err != nil {
    // TODO: handle error
}

Обзор ChainedTokenCredential

ChainedTokenCredential — это пустая цепочка, в которую вы добавляете учетные данные в соответствии с потребностями вашего приложения. Например:

managed, err := azidentity.NewManagedIdentityCredential(nil)
if err != nil {
  // handle error
}

azCLI, err := azidentity.NewAzureCLICredential(nil)
if err != nil {
  // handle error
}

chain, err := azidentity.NewChainedTokenCredential([]azcore.TokenCredential{managed, azCLI}, nil)
if err != nil {
  // handle error
}

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

Подсказка

Для повышения производительности оптимизируйте порядок учетных данных в ChainedTokenCredential для рабочей среды. Учетные данные, предназначенные для использования в локальной среде разработки, должны быть добавлены последним.

Руководство по использованию по DefaultAzureCredential

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

• Определенная реализация учетных данных, например ManagedIdentityCredential.
• Упрощённая реализация ChainedTokenCredential, оптимизированная для среды Azure, в которой запускается ваше приложение.

Вот почему:

• проблемы отладки. При сбое проверки подлинности может быть сложно выполнить отладку и идентификацию учетных данных. Необходимо включить ведение журнала, чтобы увидеть переход от одной учетной записи к следующей и успешное/неуспешное состояние их. Дополнительные сведения см. в разделе Отладка цепочки учетных данных.
• Нагрузка на производительность. Процесс последовательной проверки нескольких учетных записей может привести к нагрузке на производительность. Например, при запуске на локальном компьютере разработки управляемое удостоверение недоступно. Следовательно, ManagedIdentityCredential всегда дает сбой в локальной среде разработки, если только явно не отключается с помощью соответствующего свойства с префиксом exclude.
• Непредсказуемое поведение: DefaultAzureCredential Проверяет наличие определенных переменных среды . Возможно, кто-то может добавить или изменить эти переменные среды на уровне системы на хост-компьютере. Эти изменения применяются глобально и поэтому изменяют поведение DefaultAzureCredential во время выполнения в любом приложении, работающем на этом компьютере.

Отладка цепочки учетных данных

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

import azlog "github.com/Azure/azure-sdk-for-go/sdk/azcore/log"
// print log output to stdout
azlog.SetListener(func(event azlog.Event, s string) {
    fmt.Println(s)
})
// include only azidentity credential logs
azlog.SetEvents(azidentity.EventAuthentication)

Рекомендации по устранению ошибок из определенных типов учетных данных см. в руководстве по устранению неполадок .