Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье приводятся пошаговые инструкции для разработчиков и администраторов по настройке безопасной проверки подлинности приложений и доступа к 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 с активной подпиской— создание учетной записи бесплатно
- Существующий ресурс GeoCatalog.
Приложения, работающие в 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 приложения с делегированными разрешениями, выполнив следующие действия.
- Вход в Центр администрирования Microsoft Entra
- Перейдите к Identity>Applications>регистрации приложений, и выберите клиентское приложение.
- В разделе "Управление" выберите разрешения API
- Выберите "Добавить разрешение"
- Выберите вкладку API, которые использует моя организация
- Введите орбитальный планетарный компьютер Azure в поле поиска
- Выберите соответствующую запись (идентификатор приложения должен иметь значение 6388acc4-795e-43a9-a320-33075c1eb83b). Она отображается как Azure Orbital Microsoft Planetary Computer Pro.
- Установите флажок "Делегированные разрешения". Установите флажок рядом с user_impersonation.
- Нажмите кнопку Добавить разрешения.
- Выберите ссылку "Предоставление согласия администратора" (если вы хотите предоставить согласие администратора в аренде для данного разрешения).
Шаблон делегированной проверки подлинности также используется при подключении из QGIS.
Конфигурация Microsoft Planetary Computer Pro RBAC для приложений
После создания управляемого удостоверения для приложения, работающего в Azure, или служебного субъекта для приложения, не работающего в Azure, но зарегистрированного в Microsoft Entra, необходимо предоставить этим удостоверениям необходимые разрешения для доступа к ресурсу GeoCatalog через настройку управления доступом на основе ролей (RBAC).
Ниже приведен пошаговый пример настройки Role-Based управления доступом (RBAC) для назначения роли "Администратор GeoCatalog" управляемому удостоверению, назначенному пользователем приложения. Эти же действия можно выполнить на портале Azure, чтобы настроить RBAC для субъекта-службы приложения.
На портале Azure перейдите слева на вкладку IAM ресурса Microsoft Planetary Computer Pro.
Выберите Добавить назначение ролей, а затем выберите Администратор GeoCatalog в разделе "Роли должностных функций"
Нажмите кнопку Далее, а затем выберите переключатель (радиокнопка) управляемой идентификации
Выберите "Выбрать участников" и выберите подписку и назначаемое пользователем управляемое удостоверение на панели "Выбор управляемых удостоверений " справа.
Нажмите кнопку "Далее", чтобы проверить сведения и завершить проверку и назначить.
Получение токена доступа, чтобы получить доступ к 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».