Проверка подлинности приложений Go в службах Azure во время локальной разработки с помощью учетных записей разработчиков
Когда разработчики создают облачные приложения, они обычно отлаживают и тестируют их на локальной рабочей станции. Когда приложение выполняется на рабочей станции разработчика во время локальной разработки, оно по-прежнему должно пройти проверку подлинности в любых службах Azure, используемых приложением. В этой статье описывается, как использовать учетные данные разработчика Azure для проверки подлинности приложения в Azure во время локальной разработки.
Чтобы приложение выполняло проверку подлинности в Azure во время локальной разработки, используя учетные данные Azure разработчика, разработчик должен авторизоваться в Azure через Azure CLI или Azure Developer CLI. Пакет SDK Azure для Go может обнаружить, что разработчик вошел в систему через один из этих инструментов, а затем получить необходимые учетные данные из кэша для аутентификации приложения в Azure от имени вошедшего пользователя.
Этот подход проще всего настроить для команды разработчиков, так как он использует преимущества существующих учетных записей Azure разработчиков. Однако учетная запись разработчика, возможно, будет иметь больше разрешений, чем необходимо приложению, поэтому она будет превышать разрешения, с которыми приложение будет работать в эксплуатации. В качестве альтернативы, можно создавать учетные записи служб приложений, которые можно использовать во время локальной разработкии обладать только тем доступом, который необходим приложению.
1. Создание группы безопасности Microsoft Entra для локальной разработки
Так как в приложении почти всегда работает несколько разработчиков, рекомендуется сначала создать группу безопасности Microsoft Entra, чтобы инкапсулировать роли (разрешения), необходимые приложению в локальной разработке. Этот подход предлагает следующие преимущества.
- Каждому разработчику гарантировано назначение тех же ролей, так как роли назначаются на уровне группы.
- Если для приложения требуется новая роль, ее необходимо добавить в соответствующую группу Microsoft Entra для приложения.
- Если новый разработчик присоединяется к команде, они просто должны быть добавлены в правильную группу Microsoft Entra, чтобы получить правильные разрешения для работы с приложением.
Если у вас есть существующую группу безопасности Microsoft Entra для вашей группы разработки, можно использовать эту группу. В противном случае выполните следующие действия, чтобы создать группу безопасности Microsoft Entra.
Команда az ad group create используется для создания групп в системе Microsoft Entra ID. Требуются параметры --display-name
и --main-nickname
. Имя, заданное группе, должно быть основано на имени приложения. Также полезно включить фразу, например local-dev, в имя группы, чтобы указать назначение группы.
az ad group create \
--display-name MyDisplay \
--mail-nickname MyDisplay \
--description "<group-description>"
Скопируйте значение свойства id
в выходных данных команды. Это идентификатор объекта для группы. Вам потребуется это в последующих шагах. Вы также можете использовать команду az ad group show для получения этого свойства.
Чтобы добавить участников в группу, вам потребуется идентификатор объекта пользователя Azure. Используйте az ad user list для перечисления доступных субъектов-служб. Команда параметра --filter
принимает фильтры в стиле OData и может использоваться для фильтрации списка по отображаемому имени пользователя. Параметр --query
ограничивает выходные данные столбцами, интересующими вас.
az ad user list \
--filter "startswith(displayName, 'Bob')" \
--query "[].{objectId:id, displayName:displayName}" \
--output table
Затем команду az ad group member add можно использовать для добавления членов в группы.
az ad group member add \
--group <group-name> \
--member-id <object-id>
Заметка
По умолчанию создание групп безопасности Microsoft Entra ограничено определенными привилегированными ролями в каталоге. Если вы не можете создать группу, обратитесь к администратору каталога. Если вы не можете добавить участников в существующую группу, обратитесь к владельцу группы или администратору каталога. Дополнительные сведения см. в статье Управление группами Microsoft Entra и членством в группах.
2. Назначение ролей группе Microsoft Entra
Затем необходимо определить, какие роли (разрешения) приложения требуются для ресурсов и назначить эти роли приложению. В этом примере роли будут назначены группе Microsoft Entra, созданной на шаге 1. Роли можно назначать в ресурсе, группе ресурсов или области подписки. В этом примере показано, как назначать роли в области группы ресурсов, поскольку большинство приложений группируют все ресурсы Azure в одну группу ресурсов.
Пользователю, группе или субъекту-службе приложений назначена роль в Azure с помощью команды az role assignment create. Группу можно указать с идентификатором объекта.
az role assignment create --assignee <objectId> \
--scope /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName> \
--role "<roleName>"
Чтобы получить имена ролей, которые можно назначить, используйте команду az role definition list.
az role definition list --query "sort_by([].{roleName:roleName, description:description}, &roleName)" --output table
Например, чтобы разрешить членам группы с идентификатором объекта bbbbbbbb-1111-2222-3333-cccccccccccc
доступ на чтение, запись и удаление в контейнерах BLOB-объектов хранилища Azure и данных во всех учетных записях хранения в группе ресурсов msdocs-go-sdk-auth-example в подписке с идентификатором aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e
, вы назначите группе роль Участник данных BLOB хранилища с помощью следующей команды.
az role assignment create --assignee bbbbbbbb-1111-2222-3333-cccccccccccc \
--scope /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-go-sdk-auth-example \
--role "Storage Blob Data Contributor"
Сведения о назначении разрешений на уровне ресурса или подписки с помощью Azure CLI см. в статье Назначение ролей Azure с помощьюAzure CLI.
3. Вход в Azure с помощью Azure CLI или Интерфейса командной строки разработчика Azure
Откройте терминал на рабочей станции разработчика и войдите в Azure из Azure CLI.
az login
4. Реализация DefaultAzureCredential в приложении
Для проверки подлинности клиентских объектов Пакета SDK Azure в Azure приложение должно использовать класс DefaultAzureCredential
. В этом сценарии DefaultAzureCredential
будет последовательно проверять, выполнил ли разработчик вход в Azure с помощью Azure CLI или Интерфейса командной строки разработчика Azure. Если разработчик вошел в Azure с помощью одного из этих средств, учетные данные, используемые для входа в средство, будут использоваться приложением для проверки подлинности в Azure.
Сначала добавьте пакет azidentity
в приложение.
go get github.com/Azure/azure-sdk-for-go/sdk/azidentity
Затем для любого кода Go, создающего клиентский объект Azure SDK в приложении, необходимо выполнить следующие действия.
- Импортируйте пакет
azidentity
. - Создайте экземпляр типа
DefaultAzureCredential
. - Передайте экземпляр типа
DefaultAzureCredential
конструктору клиента Azure SDK.
Пример этих шагов показан в следующем сегменте кода.
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>)
}