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

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

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

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

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

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

• Azure CLI (az login)
• Интерфейс командной строки разработчика Azure (azd login)
• Azure PowerShell (Connect-AzAccount)

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

Это поведение активируется при использовании DefaultAzureCredential, который в локальных средах автоматически переключается на учетные данные, основанные на интерфейсе командной строки.

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

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

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

Разработчики могут настроить локальную среду для использования субъекта-службы с помощью переменных среды и DefaultAzureCredential автоматически забрать ее. Дополнительные сведения см. в статье Аутентификация приложений Python в службах Azure во время локальной разработки с помощью субъектов-служб.

1. Создание группы безопасности Microsoft Entra для локальной разработки

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

Назначение ролей Azure на уровне группы вместо отдельных пользователей предлагает несколько ключевых преимуществ:

• Последовательные назначения ролей

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

• Упрощенное управление ролями

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

• Простая адаптация

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

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

Azure CLI

Чтобы создать группу безопасности в Microsoft Entra ID, используйте команду Azure CLI az ad group create.

Для этой команды требуются следующие параметры:

--display-name: понятное имя для группы

--mail-nickname: уникальный идентификатор, используемый для электронной почты и внутренней ссылки

Рекомендуется оснoвывать имя группы на имени приложения и добавлять суффикс, такой как -local-dev, чтобы четко указать его назначение.

#!/bin/bash
az ad group create \
    --display-name MyDisplay \
    --mail-nickname MyDisplay  \
    --description "<group-description>"

# PowerShell syntax
az ad group create `
    --display-name MyDisplay `
    --mail-nickname MyDisplay `
    --description "<group-description>"

После выполнения az ad group create команды скопируйте значение id свойства из выходных данных команды. Вам необходимо иметь Object ID идентификатор группы безопасности Microsoft Entra для назначения ролей на следующих этапах этой статьи. Чтобы получить Object ID еще раз позже, используйте следующую команду az ad group show: az ad group show --group "my-app-local-dev" --query id --output tsv.

Чтобы добавить пользователя в группу, сначала необходимо получить Object ID учетную запись пользователя Azure, которую вы хотите добавить. Используйте команду az ad user list с параметром --filter для поиска определенного пользователя по отображаемого имени. Параметр --query помогает ограничить выходные данные соответствующими полями:

#!/bin/bash
az ad user list \
--filter "startswith(displayName, 'Bob')" \
--query "[].{objectId:id, displayName:displayName}" \
--output table

# PowerShell syntax
az ad user list `
    --filter "startswith(displayName, 'Bob')" `
    --query "[].{objectId:id, displayName:displayName}" `
    --output table

Object ID Получив пользователя, вы можете добавить их в группу с помощью команды az ad group member add.

#!/bin/bash
az ad group member add \
    --group <group-name> \
    --member-id <object-id>

# PowerShell syntax
az ad group member add `
    --group <group-name> `
    --member-id <object-id>

Портал Azure

Инструкции	Снимок экрана
Перейдите на страницу Microsoft Entra ID в портале Azure, введя Microsoft Entra ID в поле поиска в верхней части страницы, а затем выберите Microsoft Entra ID из служб.
На странице Microsoft Entra ID выберите Группы в меню слева.
На странице "Все группы" выберите "Создать группу".
На странице "Новая группа": Тип группы → Security. Имя группы → Имя группы безопасности, которое обычно создается из имени приложения. Также полезно включить строку, например local-dev в имя группы, чтобы указать назначение группы. Описание группы → Описание цели группы. Выберите ссылку "Нет участников", выбранную в разделе "Участники", чтобы добавить участников в группу.
В диалоговом окне "Добавление элементов": Используйте поле поиска для фильтрации списка имен пользователей в списке. Выберите одного или нескольких пользователей для локальной разработки для этого приложения. При выборе объекта объект перемещается в список выбранных элементов в нижней части диалогового окна. По завершении нажмите кнопку "Выбрать ".
Вернитесь на страницу "Создать группу ", выберите "Создать ", чтобы создать группу. Группа будет создана, и вы вернеесь на страницу "Все группы ". Для отображения группы может потребоваться до 30 секунд, и может потребоваться обновить страницу из-за кэширования в портал Azure.

Примечание.

По умолчанию создание групп безопасности Microsoft Entra ограничено определенными привилегированными ролями в каталоге. Если вы не можете создать группу, обратитесь к администратору каталога. Если вы не можете добавить участников в существующую группу, обратитесь к владельцу группы или администратору каталога. Дополнительные сведения см. в статье "Управление группами Microsoft Entra" и членством в группах.

2. Назначение ролей группе Microsoft Entra

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

• Определение обязательных ролей

  Определите роли, необходимые приложению. Распространенные примеры:

  • Пользователь секретов Key Vault — для чтения секретов из Azure Key Vault
  • Участник данных очереди хранилища – для отправки сообщений в хранилище очереди Azure

  Дополнительные параметры см. в встроенных определениях ролей.

• Выбор области назначения ролей

  Роли можно назначать в разных областях:

  • Уровень ресурсов (например, одна учетная запись Key Vault или учетная запись хранения)
  • Уровень группы ресурсов (рекомендуется для большинства приложений)
  • Уровень подписки (используйте с осторожностью — самый широкий доступ)

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

Azure CLI

Пользователю, группе или субъекту-службе приложений назначается роль в Azure с помощью команды az role assignment create . Можно указать группу с помощью Object ID.

#!/bin/bash
az role assignment create --assignee <objectId> \
    --scope /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName> \
    --role "<roleName>" 

# PowerShell syntax
az role assignment create `
    --assignee <objectId> `
    --scope /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName> `
    --role "<roleName>"

Чтобы получить имена ролей, которые можно назначить, используйте команду az role definition list .

#!/bin/bash
az role definition list --query "sort_by([].{roleName:roleName, description:description}, &roleName)" --output table

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

Чтобы предоставить доступ к чтению, записи и удалению контейнеров и данных BLOB-объектов хранилища Azure для всех учетных записей хранения в определенной группе ресурсов, назначьте роль "Участник данных BLOB-хранилища" группе безопасности Microsoft Entra.

#!/bin/bash
az role assignment create --assignee bbbbbbbb-1111-2222-3333-cccccccccccc \
    --scope /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-python-sdk-auth-example \
    --role "Storage Blob Data Contributor"

# PowerShell syntax
az role assignment create --assignee bbbbbbbb-1111-2222-3333-cccccccccccc `
    --scope /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-python-sdk-auth-example `
    --role "Storage Blob Data Contributor"

Сведения о назначении разрешений на уровне ресурса или подписки с помощью Azure CLI см. в статье "Назначение ролей Azure с помощью Azure CLI".

Портал Azure

Инструкции	Снимок экрана
Найдите группу ресурсов для вашего приложения, введя название группы ресурсов в поле поиска в верхней части портала Azure. Перейдите к группе ресурсов, выбрав имя группы ресурсов в заголовке "Группы ресурсов" в диалоговом окне.
На странице группы ресурсов выберите элемент управления доступом (IAM) в меню слева.
На странице управления доступом (IAM): Выберите вкладку Назначения ролей. Выберите + Добавить в верхнем меню, а затем выберите Добавить назначение роли в появившемся раскрывающемся меню.
На странице "Добавление назначения ролей" перечислены все роли, которые можно назначить для группы ресурсов. Используйте поле поиска, чтобы отфильтровать список до более управляемого размера. В этом примере показано, как фильтровать роли BLOB-объектов хранилища. Выберите роль, которую вы хотите назначить. Нажмите кнопку "Далее ", чтобы перейти к следующему экрану.
На следующей странице "Добавление назначения ролей" можно указать, какой пользователь назначит роль. Выберите "Пользователь", "Группа" или "Субъект-служба" в разделе "Назначение доступа". Выбор и выбор элементов в разделе "Элементы" Откроется диалоговое окно справа от портал Azure.
В диалоговом окне выбора элементов: Текстовое поле Select можно использовать для фильтрации списка пользователей и групп в подписке. При необходимости введите первые несколько символов локальной группы Microsoft Entra, созданной для приложения. Выберите локальную группу Microsoft Entra, связанную с приложением. Выберите Выберите в нижней части диалогового окна, чтобы продолжить.
Группа Microsoft Entra отображается на экране назначения ролей. Выберите Обзор + назначить, чтобы перейти на окончательную страницу, а затем Обзор + назначить еще раз, чтобы завершить процесс.

3. Вход в Azure с помощью Azure CLI, Azure PowerShell, Интерфейса командной строки разработчика Azure или в браузере

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

Azure CLI

Откройте терминал на рабочей станции разработчика и войдите в Azure из Azure CLI.

az login

Azure PowerShell

Откройте терминал на рабочей станции разработчика и войдите в Azure из Azure PowerShell.

Connect-AzAccount

Интерфейс командной строки разработчика Azure

Откройте терминал на рабочей станции разработчика и войдите в Azure из Azure Developer CLI.

azd auth login

Интерактивный браузер

Интерактивная проверка подлинности отключена по DefaultAzureCredential умолчанию и может быть включена с помощью аргумента ключевого слова:

DefaultAzureCredential(exclude_interactive_browser_credential=False)

4. Реализация DefaultAzureCredential в приложении

Чтобы проверить подлинность клиентских объектов Пакета SDK Azure в Azure, приложение должно использовать DefaultAzureCredential класс из azure-identity пакета. Это рекомендуемый метод аутентификации как для локальной разработки, так и для производственной среды.

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

• Azure CLI (az login)
• Azure PowerShell (Connect-AzAccount)
• Azure Developer CLI (azd auth login)

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

Начните с добавления пакета azure.identity в приложение.

pip install azure-identity

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

1. DefaultAzureCredential Импортируйте класс из azure.identity модуля.
2. Создание объекта DefaultAzureCredential.
3. Передайте объект конструктору DefaultAzureCredential клиентского объекта пакета SDK Azure.

Пример этих шагов показан в следующем сегменте кода.

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

# Acquire a credential object
token_credential = DefaultAzureCredential()

blob_service_client = BlobServiceClient(
        account_url="https://<my_account_name>.blob.core.windows.net",
        credential=token_credential)