Настройка проверки подлинности приложения для Microsoft Planetary Computer Pro

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

Замечание

Для приложений, использующих Azure AD B2C или Microsoft Entra External ID с поддержкой таких функций, как провайдеры социальных удостоверений, необходимо по-прежнему применять эти решения для проксирования трафика аутентификации, поскольку Planetary Computer Pro не поддерживает альтернативы аутентификации Microsoft Entra ID.

Параметры проверки подлинности и рекомендации

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

Среда размещения приложений Обязательный тип доступа Рекомендуемый тип идентификации Explanation
Использование в Azure (виртуальные машины, служба приложений, функции, контейнерные приложения и т. д.) App-Only (приложение выступает в качестве самого себя) Управляемое удостоверение (рекомендуется назначаемое пользователем) Безопасность и управляемость: Устраняет необходимость хранения учетных данных (секретов или сертификатов) и управления ими в коде или конфигурации. Azure автоматически обрабатывает смену учетных данных. Назначенное пользователем рекомендуется для совместного использования на нескольких ресурсах.
Использование в Azure (виртуальные машины, служба приложений, функции, контейнерные приложения и т. д.) Делегировано (приложение действует от имени пользователя) Управляемое удостоверение (рекомендуется назначаемое пользователем) Использует интеграцию Azure: Объединяет преимущества безопасности управляемого удостоверения для самого приложения с стандартными потоками проверки подлинности пользователей. Упрощает настройку инфраструктуры в Azure.
Запуск за пределами Azure (локальная среда, другое облако, компьютер разработчика) App-Only (приложение выступает в качестве самого себя) Служебный принципал Стандартный для внешних приложений: Установленный метод для приложений, отличных от Azure, для проверки подлинности с помощью идентификатора Microsoft Entra. Требует безопасного управления учетными данными (секретами или сертификатами).
Запуск за пределами Azure (локальная среда, другое облако, компьютер разработчика) Делегировано (приложение действует от имени пользователя) Служебный принципал Стандартный для внешних приложений: Включает стандартные потоки OAuth 2.0 для входа пользователей и согласия для приложений за пределами Azure, используя зарегистрированное удостоверение приложения в идентификаторе Entra.
Работа за пределами Azure (альтернатива) App-Only или делегировано Управляемая идентичность Приносит преимущества Azure: Размещая приложение в вычислительном сервисе Azure (например, виртуальной машине или приложении-контейнере), он может использовать повышенную безопасность и лучшее управление управляемых идентичностей, без необходимости управлять учетными данными, даже если источник может не относиться к Azure.

Предпосылки

Приложения, работающие в Azure

Для приложений, работающих в Azure, мы рекомендуем создать тип удостоверения Microsoft Entra, называемый пользовательски назначаемое управляемое удостоверение, для доступа к ресурсу GeoCatalog. Приложения могут использовать управляемые удостоверения для получения маркеров Microsoft Entra (см. раздел Получения маркера доступа для доступа к Microsoft Planetary Computer Pro без необходимости управлять учетными данными. Дополнительные сведения об управляемых удостоверениях и выбранном типе см. в разделе "Что такое управляемые удостоверения для ресурсов Azure". Чтобы создать назначаемые пользователем управляемые удостоверения для приложения, работающего в Azure, следуйте инструкциям по использованию управляемых удостоверений для службы приложений и функций Azure.

Приложения, не работающие в Azure

Для приложений, которые не работают в Azure, например локальных или размещенных в других облачных поставщиках, рекомендуется зарегистрировать приложение в Центре администрирования Microsoft Entra, включая URI перенаправления для получения маркеров безопасности, чтобы установить отношение доверия между приложением и платформой удостоверений Майкрософт. Регистрация приложения в Microsoft Entra автоматически создает служебный принципал для приложения, которому можно назначить роли RBAC позже. Если в вашем приложении есть параметр для настройки аутентификации Microsoft Entra ID, вы можете использовать "Идентификатор приложения (клиента)" и "Идентификатор каталога (арендатора)" зарегистрированного приложения для этого.

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

!az login  --identity --username <client_id|object_id|resource_id> 

Идентификатор клиента, идентификатор объекта или идентификатор ресурса управляемого удостоверения можно найти на портале Azure. В качестве альтернативы интерфейсу командной строки пример кода Python находится в разделе "Получение маркера доступа для доступа к Microsoft Planetary Computer Pro".

azure.identity.DefaultAzureCredential(managed_identity_client_id=<client_id>)

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

Доступ только для приложений

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

Делегированный доступ

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

  1. Вход в Центр администрирования Microsoft Entra
  2. Перейдите к Identity>Applications>регистрации приложений, и выберите клиентское приложение.
  3. В разделе "Управление" выберите разрешения API
  4. Выберите "Добавить разрешение"
  5. Выберите вкладку API, которые использует моя организация
  6. Введите орбитальный планетарный компьютер Azure в поле поиска
  7. Выберите соответствующую запись (идентификатор приложения должен иметь значение 6388acc4-795e-43a9-a320-33075c1eb83b). Она отображается как Azure Orbital Microsoft Planetary Computer Pro.
  8. Установите флажок "Делегированные разрешения". Установите флажок рядом с user_impersonation.
  9. Нажмите кнопку Добавить разрешения.
  10. Выберите ссылку "Предоставление согласия администратора" (если вы хотите предоставить согласие администратора в аренде для данного разрешения).

Шаблон делегированной проверки подлинности также используется при подключении из QGIS.

Конфигурация Microsoft Planetary Computer Pro RBAC для приложений

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

Ниже приведен пошаговый пример настройки Role-Based управления доступом (RBAC) для назначения роли "Администратор GeoCatalog" управляемому удостоверению, назначенному пользователем приложения. Эти же действия можно выполнить на портале Azure, чтобы настроить RBAC для субъекта-службы приложения.

  1. На портале Azure перейдите слева на вкладку IAM ресурса Microsoft Planetary Computer Pro.

    Снимок экрана панели IAM на портале Azure для настройки RBAC.

  2. Выберите Добавить назначение ролей, а затем выберите Администратор GeoCatalog в разделе "Роли должностных функций"

    Снимок экрана: выбор назначения ролей на портале Azure.

  3. Нажмите кнопку Далее, а затем выберите переключатель (радиокнопка) управляемой идентификации

    Снимок экрана: выбор управляемого удостоверения на портале Azure.

  4. Выберите "Выбрать участников" и выберите подписку и назначаемое пользователем управляемое удостоверение на панели "Выбор управляемых удостоверений " справа.

    Снимок экрана панели выбранных участников на портале Azure.

  5. Нажмите кнопку "Далее", чтобы проверить сведения и завершить проверку и назначить.

Получение токена доступа, чтобы получить доступ к Microsoft Planetary Computer Pro

После настройки RBAC для предоставления приложению соответствующих разрешений приложение должно получить маркер доступа для проверки подлинности запросов. Пример кода Python ниже:

import azure.identity
credential = azure.identity.DefaultAzureCredential()
token = credential.get_token("https://geocatalog.spatio.azure.com/")
headers = {"Authorization": f"Bearer {token.token}"} 

Замечание

Если приложению назначено несколько управляемых удостоверений, необходимо явно указать нужное: azure.identity.DefaultAzureCredential(managed_identity_client_id=<client_id>). Кроме того, можно настроить переменные среды приложения на портале Azure, чтобы добавить "AZURE_CLIENT_ID" правильный идентификатор клиента управляемого удостоверения.

Замечание

Вы можете добавить .default или user_impersonation в качестве области для credential.get_token(), в зависимости от ожидаемого поведения проверки подлинности пользователя.

Замечание

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

Более подробную информацию о маркерах доступа см. в разделе «Маркеры доступа на платформе удостоверений Microsoft». При получении токенов доступа с помощью вызова DefaultAzureCredentials(), приобретенные токены кэшируются экземпляром учетных данных. Время существования токена и его обновление обрабатываются автоматически. Вы можете передавать экземпляр DefaultAzureCredential между различными процессами и вызывать GetToken() или GetTokenAsync() непосредственно перед тем, как понадобится токен, чтобы всегда получать токен, который не истек. Если требуется поддерживать длительный открытый сеанс, можно обработать истечение срока действия токена в обработчике ошибок, чтобы поймать исключение и получить новый токен.

Если вы не можете использовать DefaultAzureCredentials() и вместо этого используете другие методы, такие как AzureCliCredential(), для получения токенов доступа, необходимо управлять временем жизни и обновлением токена. Дополнительные сведения см. в статьях «Настраиваемые время существования маркеров в платформе удостоверений Microsoft» и «Маркеры обновления в платформе удостоверений Microsoft».

Дальнейшие шаги