Как работают управляемые удостоверения ресурсов Azure с виртуальными машинами Azure.
Управляемые удостоверения для ресурсов Azure предоставляют службам Azure автоматически управляемое удостоверение, которое хранится в Microsoft Entra ID. Это удостоверение можно использовать для проверки подлинности в любой службе, которая поддерживает аутентификацию Microsoft Entra, без использования учетных данных в коде.
В этой статье вы узнаете, как управляемые удостоверения работают с виртуальными машинами Azure.
Принцип работы
На внутреннем уровне управляемые удостоверения — это субъекты-службы особого типа, которые можно использовать только с ресурсами Azure. При удалении менеджируемого удостоверения соответствующая учетная запись службы автоматически удаляется. Кроме того, при создании удостоверений, назначаемых пользователем или системой, поставщик ресурсов управляемых удостоверений (MSRP) выдает этому удостоверению внутренний сертификат.
Ваш код может использовать управляемое удостоверение для запроса токенов доступа для служб, поддерживающих аутентификацию Microsoft Entra. Azure заботится об обновлении учетных данных, используемых экземпляром службы.
На следующей диаграмме показано, как управляемые удостоверения служб работают с виртуальными машинами Azure.
В следующей таблице показаны различия между назначаемыми системой и назначаемыми пользователем управляемыми удостоверениями:
| Свойство | Управляемая учётная запись, назначаемая системой | Управляемое удостоверение, назначаемое пользователем |
|---|---|---|
| Создание | Создано как часть ресурса Azure (например, виртуальная машина Azure или Служба приложений Azure). | Создано в качестве автономного ресурса Azure. |
| Жизненный цикл | Жизненный цикл, общий с ресурсом Azure, вместе с которым создано управляемое удостоверение. При удалении родительского ресурса управляемое удостоверение также удаляется. |
Независимый жизненный цикл. Должен быть явно удален. |
| Совместное использование ресурсов Azure | Нельзя поделиться. Может быть связано только с одним ресурсом Azure. |
Может быть в общем доступе. Одно и то же назначаемое пользователем управляемое удостоверение может быть связано с несколькими ресурсами Azure. |
| Распространенные варианты использования | Рабочие нагрузки, которые содержатся в одном ресурсе Azure. Рабочие нагрузки, для которых требуются независимые удостоверения. Например, приложение, выполняющееся на одной виртуальной машине. |
Рабочие нагрузки, которые выполняются на нескольких ресурсах и могут совместно использовать одно удостоверение личности. Рабочие нагрузки, требующие предварительной авторизации к защищенному ресурсу, как часть процесса предоставления. Рабочие нагрузки, где ресурсы часто перераспределяются, но разрешения должны оставаться неизменными. Например, рабочая нагрузка, где нескольким виртуальным машинам требуется доступ к одному и тому же ресурсу. |
Системное управляемое удостоверение
Azure Resource Manager получает запрос на включение системного управляемого удостоверения на виртуальной машине.
Azure Resource Manager создает сервисный принципал в Microsoft Entra ID для удостоверения виртуальной машины. Субъект-служба создается в доверенном клиенте Microsoft Entra подписки.
Azure Resource Manager обновляет удостоверение виртуальной машины, используя конечную точку метаданных экземпляра Azure (для Windows и Linux), передавая ей идентификатор клиента и сертификат служебного субъекта.
После того как виртуальной машине было назначено удостоверение, используйте сведения об учетной записи службы, чтобы предоставить виртуальной машине доступ к ресурсам Azure. Чтобы вызвать Azure Resource Manager, используйте контроль доступа на основе ролей Azure (Azure RBAC), чтобы назначить соответствующую роль субъекту-службе виртуальной машины. Для вызова Key Vault следует предоставить доступ к определенному секрету или ключу в Key Vault.
Код, выполняющийся на виртуальной машине, может запросить токен из конечной точки сервиса метаданных экземпляра Azure, доступной только из виртуальной машины:
http://169.254.169.254/metadata/identity/oauth2/token- Параметр ресурса указывает службу, в которую отправляется маркер. Для проверки подлинности в Azure Resource Manager необходимо использовать
resource=https://management.azure.com/. - Параметр версии API указывает версию IMDS. Используйте api-version=2018-02-01 или более поздней версии.
В следующем примере демонстрируется, как использовать CURL для отправки запроса к локальной конечной точке управляемого удостоверения, чтобы получить токен доступа к службе метаданных экземпляра Azure.
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fstorage.azure.com%2F' -H Metadata:true- Параметр ресурса указывает службу, в которую отправляется маркер. Для проверки подлинности в Azure Resource Manager необходимо использовать
Делается вызов к Microsoft Entra ID для запроса токена доступа (как указано на шаге 5) с использованием идентификатора клиента и сертификата, настроенных на шаге 3. Идентификатор Microsoft Entra возвращает токен доступа JSON Web Token (JWT).
Код отправляет токен доступа при вызове службы, поддерживающей аутентификацию Microsoft Entra.
Назначаемая пользователем управляемая идентичность
Azure Resource Manager получает запрос на создание назначаемого пользователем управляемого удостоверения.
Azure Resource Manager создает учетную запись службы в Microsoft Entra ID для назначаемой пользователем управляемой идентичности. Субъект-служба создается в доверенном клиенте Microsoft Entra подписки.
Azure Resource Manager получает запрос на настройку назначаемого пользователем управляемого удостоверения на виртуальной машине и обновляет конечную точку удостоверения Службы метаданных экземпляра Azure, используя назначенный пользователем идентификатор клиента и сертификат субъекта-службы управляемого удостоверения.
После создания управляемого удостоверения, назначаемого пользователем, используйте информацию о служебном принципале для предоставления этому удостоверению доступа к ресурсам Azure. Для обращения к диспетчеру ресурсов Azure используйте Azure RBAC, чтобы назначить соответствующую роль служебному принципалу пользовательского удостоверения. Для доступа к Key Vault следует предоставить вашему коду доступ к конкретному секрету или ключу.
Примечание.
Также данное действие можно выполнить перед шагом 3.
Код, выполняющийся на виртуальной машине, может запросить токен из конечной точки Службы метаданных экземпляров Azure, доступной только из виртуальной машины:
http://169.254.169.254/metadata/identity/oauth2/tokenПараметр ресурса указывает службу, в которую отправляется маркер. Для проверки подлинности в Azure Resource Manager необходимо использовать
resource=https://management.azure.com/.Параметр
client_idзадает удостоверение, для которого запрашивается токен. Это значение необходимо для устранения неоднозначности, когда на одной виртуальной машине присутствуют несколько идентификаций, назначенных пользователем. Идентификатор клиента можно найти в разделе Обзор управляемого удостоверения.
Параметры версии API указывают версию Службы метаданных экземпляров Azure. Используйте
api-version=2018-02-01или выше.В следующем примере показано, как использовать CURL для запроса к локальной конечной точке управляемого удостоверения, чтобы получить токен доступа для службы метаданных Azure.
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fstorage.azure.com%2F&client_id=00001111-aaaa-2222-bbbb-3333cccc4444' -H Metadata:true
Был осуществлён запрос к Microsoft Entra ID для получения токена доступа (как указано на шаге 5) с использованием идентификатора клиента и сертификата, настроенного на шаге 3. Microsoft Entra ID возвращает токен доступа веб-токена JSON (JWT).
Ваш код передает токен доступа при вызове службы, поддерживающей аутентификацию Microsoft Entra.
Следующие шаги
Чтобы начать работу с функцией управляемых удостоверений для ресурсов Azure, воспользуйтесь следующими краткими руководствами: