Предоставление субъекту-службе доступа к Azure

  • 6 мин

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

Примечание.

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

Авторизация субъекта-службы

До сих пор вы сосредоточились на том, какие субъекты-службы и как их можно использовать для подтверждения удостоверения конвейера в идентификатор Microsoft Entra ID. Все это связано с аутентификацией.

После проверки подлинности субъекта-службы идентификатора Microsoft Entra возникает следующий вопрос: что может сделать этот субъект-служба? Это концепция авторизации. За нее отвечает система управления доступом на основе ролей Azure (RBAC), иногда называемая системой управления идентификацией и доступом (IAM). С помощью Azure RBAC можно предоставить субъекту-службе доступ к определенной группе ресурсов, подписке или группе управления.

Примечание.

Все, что вы делаете здесь, — это используете систему Azure RBAC, чтобы предоставить доступ для создания и управления ресурсами Azure, такими как учетные записи хранения, план службы приложений и виртуальные сети. Идентификатор Microsoft Entra id также имеет собственную систему ролей, которая иногда называется ролями каталогов. Эти роли используются для предоставления разрешений субъектам-службам для управления идентификатором Microsoft Entra. В этом модуле мы не будем углубляться в данную тему, но следует иметь в виду, что термин роль в некоторых документах может быть связан и с тем, и с другим.

Выбор верного назначения ролей для конвейера

Назначение ролей состоит из трех ключевых частей: кому назначена роль (уполномоченный), что она позволяет делать (роль) и к каким ресурсам эта роль применяется (область).

Уполномоченный

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

Роль

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

  • Читатель — позволяет уполномоченным пользователям считывать информацию о ресурсах, но не дает менять и удалять их.
  • Участник — позволяет уполномоченным пользователям создавать ресурсы, а также читать и изменять уже существующие ресурсы. Однако участники не могут предоставлять доступ к ресурсам другим субъектам.
  • Владелец — обеспечивает полный контроль над ресурсами, включая предоставление доступа другим субъектам.

Внимание

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

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

Примечание.

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

Область

Необходимо определить, насколько широко назначается роль. Это решение влияет на количество ресурсов, которые может изменять субъект-служба. Существует несколько общий областей.

  • Один ресурс — можно предоставить доступ только к определенному ресурсу. Как правило, конвейеры развертывания не используют эту область, так как создают ресурсы, которых еще не существует, либо перестраивают несколько ресурсов.
  • Группа ресурсов. Можно предоставить доступ ко всем ресурсам в группе ресурсов. Участники и владельцы также могут создавать ресурсы внутри группы. Это хороший вариант для многих конвейеров развертывания.
  • Подписка. Можно предоставить доступ ко всем ресурсам в рамках подписки. При наличии нескольких приложений, рабочих нагрузок или сред в одной подписке можно предоставить разрешения для области действия этой подписки. Однако для конвейера развертывания это, как правило, слишком широкие разрешения. Вместо этого следует рассмотреть возможность определения назначений ролей группам ресурсов, если только рабочий процесс развертывания не должен создавать группы ресурсов.

Помните, что назначения ролей наследуются. Если назначить роль из группы подписки, то уполномоченный получит доступ ко всем ресурсам и их группам в этой подписке.

Выбор правильного назначения роли

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

  • Используйте самые строгие роли из возможных. Если ваш конвейер будет развертывать только базовые шаблоны Bicep и не будет управлять назначениями ролей, не используйте роль владельца.
  • Используйте самую узкую область из возможных. Большинству конвейеров необходимо развертывать ресурсы только в группу ресурсов, поэтому им не следует предоставлять назначения ролей в области подписки.
  • Для многих конвейеров хорошим выбором по умолчанию станет назначение роли участника в области группы ресурсов.
  • Учитывайте все, что делает ваш конвейер, и может начать делать в будущем. Например, вы можете создать пользовательское определение роли для конвейера развертывания веб-сайта и предоставить разрешения только для службы приложений и Application Insights. В следующем месяце к вашему файлу Bicep может понадобиться добавить учетную запись Azure Cosmos DB, но эта пользовательская роль будет блокировать создание ресурсов Azure Cosmos DB. Поэтому, чтобы избежать постоянного изменения определений ролей, лучше использовать встроенные роли или их комбинацию. Используйте политику Azure, чтобы применить требования вашей системы управления к разрешенным службам, номерам SKU и местам.
  • Проверьте конвейер, чтобы убедиться в работе назначения роли.

Смешивание и совмещение назначений ролей

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

Работа с несколькими средами

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

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

Создание назначения роли для субъекта-службы

Чтобы создать назначение роли для субъекта-службы, используйте команду az role assignment create. Необходимо указать уполномоченного, роль и область:

az role assignment create \
  --assignee 00001111-aaaa-2222-bbbb-3333cccc4444 \
  --role Contributor \
  --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite" \
  --description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Давайте рассмотрим каждый аргумент.

  • --assignee задает субъект-службу. Во избежание неоднозначности рекомендуется использовать идентификатор приложения.
  • --role задает роль. Если используется встроенная роль, ее можно указать по имени. При использовании пользовательского определения роли укажите полный идентификатор определения роли.
  • --scope задает область. Обычно это идентификатор одиночного ресурса, группы ресурсов или подписки.
  • --description — это понятное описание назначения роли.

Чтобы создать назначение роли для субъекта-службы, используйте командлет New-AzRoleAssignment. Необходимо указать уполномоченного, роль и область:

New-AzRoleAssignment `
  -ApplicationId 00001111-aaaa-2222-bbbb-3333cccc4444 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite' `
  -Description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Давайте рассмотрим каждый аргумент.

  • -ApplicationId задает идентификатор регистрации приложения субъекта-службы.
  • -RoleDefinitionName задает имя встроенной роли. При использовании пользовательского определения роли вместо этого укажите полный идентификатор определения роли с помощью аргумента -RoleDefinitionId.
  • -Scope задает область. Обычно это идентификатор одиночного ресурса, группы ресурсов или подписки.
  • -Description — это понятное описание назначения роли.

Совет

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

Примечание.

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

Создание субъекта-службы и назначения роли с помощью одной операции

Вы также можете создать назначение роли одновременно с созданием субъекта-службы. Код аналогичен команде, которая использовалась для создания субъекта-службы в предыдущих уроках, но с дополнительными аргументами:

az ad sp create-for-rbac \
  --name MyPipeline \
  --role Contributor \
  --scopes "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite"

$servicePrincipal = New-AzADServicePrincipal `
  -DisplayName MyPipeline `
  -Role Contributor `
  -Scope '/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite'

Предоставление доступа с помощью Bicep

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

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2023-04-01-preview' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment pipeline for the company\'s website needs to be able to create resources within the resource group.'
  }
}

Давайте рассмотрим каждый аргумент.

  • name — это уникальный идентификатор назначения роли. Он должно быть в виде глобального уникального идентификатора (GUID). Для создания GUID рекомендуется использовать функцию Bicep guid(), а также использовать идентификатор субъекта, идентификатор определения роли и область в качестве начальных аргументов этой функции, чтобы создаваемое имя точно было уникальным для каждого назначения роли.
  • Для principalType необходимо задать ServicePrincipal.
  • roleDefinitionId — это полный идентификатор ресурса для назначаемого определения роли. В основном вы будете работать со встроенными ролями, и вы найдете идентификатор определения роли в документации по встроенным ролям Azure. Например, у роли участника идентификатор определения роли b24988ac-6180-42a0-ab88-20f7382dd24c. При указании его в файле Bicep вы выражаете его в виде полного идентификатора ресурса, например /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c.
  • principalId – идентификатор объекта субъекта-службы. Убедитесь, что не используете идентификатор приложения или идентификатор объекта регистрации приложения.
  • description — это понятное описание назначения роли.