Архитектура Azure Lighthouse

  • Статья

С помощью Azure Lighthouse поставщики услуг могут упростить привлечение и подключение клиентов, одновременно управляя делегированными ресурсами в нужном масштабе с гибкостью и точностью. Авторизованные пользователи, группы и субъекты-службы могут работать непосредственно в контексте подписки клиента, не имея учетной записи в этом клиенте Microsoft Entra или являясь совладельцем клиента клиента. Механизм, используемый для поддержки этого доступа, называется управлением делегированными ресурсами Azure.

Diagram illustrating Azure delegated resource management.

Совет

Azure Lighthouse также можно использовать в пределах предприятия, в котором несколько клиентов Microsoft Entra имеют собственные возможности для упрощения управления несколькими клиентами.

В этой статье рассматриваются связи между клиентами в Azure Lighthouse и ресурсы, созданные в клиенте заказчика, которые включают эту связь.

Примечание.

Для подключения клиента к Azure Lighthouse требуется развертывание с помощью негостевой учетной записи в арендаторе клиента, которая имеет роль с разрешением Microsoft.Authorization/roleAssignments/write, например Владелец, для подключаемой подписки (или для той, которая содержит подключаемые группы ресурсов).

Ресурсы делегирования, созданные в клиенте заказчика

При подключении подписки или группы ресурсов заказчика к Azure Lighthouse создаются два ресурса: определение регистрации и назначение регистрации. Для доступа к этим ресурсам или работы с ними на портале Azure можно использовать API-интерфейсы и средства управления.

Определение регистрации

Определение регистрации содержит сведения о предложении Azure Lighthouse (идентификатор управляющего клиента и авторизации, которые назначают встроенные роли конкретным пользователям, группам и (или) субъектам-службам в управляющем клиенте).

Определение регистрации создается на уровне подписки для каждой делегированной подписки или в каждой подписке, содержащей делегированную группу ресурсов. При использовании API-интерфейсов для создания определения регистрации необходимо работать на уровне подписки. Например, если вы используете Azure PowerShell, перед созданием нового определения регистрации (New-New-AzManagedServicesDefinition) следует применить New-AzureRmDeployment, а не New-AzureRmResourceGroupDeployment.

Назначение регистрации

При назначении регистрации конкретной области (то есть подключенным подпискам и (или) группам ресурсов) назначается определение регистрации.

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

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

Логическая проекция

Azure Lighthouse логически проецирует ресурсы одного клиента на другой. Это позволяет пользователям авторизованного поставщика услуг входить в свой клиент с авторизацией для работы в делегированных подписках и группах ресурсов заказчика. Затем пользователи в клиенте поставщика услуг могут выполнять операции управления от имени своих заказчиков без необходимости входить в систему каждого отдельного клиента.

Каждый раз, когда пользователь, группа или субъект-служба в клиенте поставщика услуг обращается к ресурсам в клиенте заказчика, Azure Resource Manager получает запрос. Resource Manager проверяет подлинность этих запросов так же, как он делает это для запросов, отправленных пользователями в рамках собственного клиента заказчика. В Azure Lighthouse для этого подтверждается наличие двух ресурсов (определения регистрации и назначения регистрации) в клиенте заказчика. Если ресурсы имеются, Resource Manager авторизует доступ в соответствии со сведениями, определенными этими ресурсами.

Diagram illustrating the logical projection in Azure Lighthouse.

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

Принцип работы Azure Lighthouse

Далее приводится описание общего принципа работы Azure Lighthouse на примере управляющего клиента:

  1. Вы определяете роли, которые потребуются вашим группам, субъектам-службам или пользователям для управления ресурсами Azure клиента.
  2. Вы указываете этот доступ и подключаете заказчика к Azure Lighthouse либо путем публикации предложения управляемой службы в Azure Marketplace, либо путем развертывания шаблона Azure Resource Manager. В процессе подключения в клиенте заказчика создаются два описанных выше ресурса (определение регистрации и назначение регистрации).
  3. После подключения заказчика авторизованные пользователи могут входить в систему вашего управляющего клиента и выполнять задачи в заданной области заказчика (подписке или группе ресурсов) на основе определенного вами доступа. Заказчики могут просматривать все выполненные действия, а также удалять доступ в любое время.

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

Следующие шаги