Создание идентификации рабочей нагрузки для рабочего процесса в GitHub Actions

  • 5 мин

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

Создание приложения Microsoft Entra

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

Заметка

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

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

Совет

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

Ниже приведен пример команды Azure CLI для создания нового приложения Microsoft Entra:

az ad app create --display-name $applicationRegistrationName

Ниже приведен пример команды Azure PowerShell для создания нового приложения Microsoft Entra:

New-AzADApplication -DisplayName $applicationRegistrationName

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

  • идентификатор приложения. Регистрация приложения имеет уникальный идентификатор, часто называемый идентификатором приложения или иногда идентификатором клиента. Этот идентификатор используется, когда рабочий процесс должен войти в Azure.
  • идентификатор объекта. Регистрация приложения имеет идентификатор объекта, который является уникальным идентификатором, назначенным идентификатором Microsoft Entra. Вы увидите пример использования идентификатора объекта далее в этом модуле.

При создании регистрации приложения обычно задается только отображаемое имя. Azure автоматически назначает другие имена и идентификаторы.

Осторожность

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

Федеративные учетные данные

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

При создании федеративных учетных данных для рабочего процесса развертывания вы по сути говорите Microsoft Entra ID и GitHub доверять друг другу. Это доверие называется федерацией .

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

  • Имя пользователя или организации GitHub.
  • Имя репозитория GitHub.
  • Ветвь вашего репозитория, на которой в настоящее время выполняется рабочий процесс.
  • Среда, на которую нацелено задание рабочего процесса. Дополнительные сведения о средах см. в следующем модуле.
  • Было ли создание запроса на вытягивание триггером для запуска рабочего процесса.

Вы можете настроить идентификатор Microsoft Entra, чтобы разрешить или запретить попытку входа из GitHub в зависимости от значений свойств, перечисленных ранее. Например, можно применить следующие политики:

  • При запуске рабочего процесса из определенного репозитория GitHub в моей организации допускается только попытка входа.
  • разрешать попытки входа только при запуске рабочего процесса из определенного репозитория GitHub в моей организации, и имя ветки — main.

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

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

Ниже приведены действия, связанные с процессом входа.

  1. Когда рабочий процесс должен взаимодействовать с Azure, GitHub безопасно обращается к Microsoft Entra ID, чтобы запросить токен доступа . GitHub предоставляет сведения о организации GitHub (my-github-user), репозитории (my-repo) и ветви, в которой выполняется рабочий процесс (main). Кроме того, он содержит идентификатор клиента Microsoft Entra ID, идентификатор приложения регистрации личности рабочего процесса и идентификатор подписки Azure, в которую нужно развернуть рабочий процесс.

  2. Идентификатор Microsoft Entra проверяет идентификатор приложения и проверяет, существует ли федеративные учетные данные в приложении для организации, репозитория и ветви GitHub.

  3. После того как идентификатор Microsoft Entra определяет, что запрос действителен, он выдает маркер доступа. Рабочий процесс использует маркер доступа при обмене данными с Azure Resource Manager.

Создайте федеративные учетные данные

При использовании Azure CLI необходимо определить федеративные учетные данные, создав JSON-файл или переменную. Например, просмотрите следующий JSON-файл:

{
  "name": "MyFederatedCredential",
  "issuer": "https://token.actions.githubusercontent.com",
  "subject": "repo:my-github-user/my-repo:ref:refs/heads/main",
  "audiences": [
    "api://AzureADTokenExchange"
  ]
}

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

Поле Ценность
Название организации GitHub my-github-user
Имя репозитория GitHub my-repo
Имя ветви main

После создания политики в ФОРМАТЕ JSON и сохранения его в файл с именем policy.jsonможно использовать Azure CLI для создания федеративных учетных данных:

az ad app federated-credential create \
  --id $applicationRegistrationObjectId \
  --parameters @policy.json

При использовании Azure PowerShell необходимо определить федеративные учетные данные, создав строку, аналогичную следующей:

$policy = "repo:my-github-user/my-repo:ref:refs/heads/main"

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

Поле Ценность
Название организации GitHub my-github-user
Имя репозитория GitHub my-repo
Имя ветви main

После создания строки политики можно использовать Azure PowerShell для создания федеративных учетных данных:

New-AzADAppFederatedCredential `
  -Name 'MyFederatedCredential' `
  -ApplicationObjectId $applicationRegistrationObjectId `
  -Issuer 'https://token.actions.githubusercontent.com' `
  -Audience 'api://AzureADTokenExchange' `
  -Subject $policy

Управление жизненным циклом идентификатора нагрузки

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

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

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

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

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