OpenID Connect

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

В этой статье

Обзор OpenID Connect (OIDC)

Рабочие процессы GitHub Actions часто предназначены для доступа к облачному провайдеру (такому как AWS, Azure, GCP, HashiCorp Vault и другим) с целью развертывания программного обеспечения или использования облачных сервисов. Прежде чем рабочий процесс сможет получить доступ к ресурсам, он должен предоставить поставщику облачных служб учетные данные, например пароль или токен. Эти учетные данные обычно хранятся на GitHub в виде секрета, который предоставляется поставщику облачных служб при каждом запуске рабочего процесса.

Однако для использования жестко заданных секретов необходимо создать учетные данные в поставщике облачных служб, а затем дублировать их на GitHub в качестве секрета.

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

Преимущества использования OIDC

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

  •         **Нет облачных секретов:** вам не нужно дублировать свои облачные учетные данные в течение длительного времени GitHub секретов. Вместо этого можно настроить отношение доверия к OIDC в системе поставщика облачных служб, а затем изменить рабочие процессы для запроса кратковременного маркера доступа у поставщика облачных служб через OIDC.

  •         **Управление проверкой подлинности и авторизацией**. Вы получаете более детальный контроль над использованием учетных данных рабочими процессами и можете применять средства проверки подлинности и авторизации поставщика облачных служб для управления доступом к облачным ресурсам.

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

Интеграция OIDC с GitHub Actions

На следующей схеме представлен обзор интеграции поставщика OIDC GitHubс рабочими процессами и поставщиком облачных служб:

Схема интеграции поставщика облачных служб с GitHub Actions с помощью маркеров доступа и идентификаторов облачных ролей веб-токена JSON.

  1. Вы устанавливаете отношение доверия OIDC в поставщике облачных служб, позволяя определенным рабочим процессам GitHub запрашивать маркеры доступа к облаку от имени определенной облачной роли.
  2. При каждом запуске задания GitHubпоставщика OIDC автоматически создает маркер OIDC. Этот токен содержит несколько утверждений для надежной и проверяемой идентификации рабочего процесса, который пытается пройти проверку подлинности.
  3. Шаг или действие в задании рабочего процесса может запросить токен от поставщика OIDC GitHub, который затем может быть представлен поставщику облачных служб в качестве подтверждения удостоверения рабочего процесса.
  4. После того как поставщик облачных служб успешно проверит утверждения, представленные в токене, он предоставит кратковременный маркер доступа к облаку, который действует только в течение выполнения задания.

Основные сведения о токене OIDC

Каждое задание запрашивает токен OIDC у поставщика OIDC GitHub, который предоставляет в ответ автоматически созданный токен JSON Web Token (JWT), уникальный для задания рабочего процесса. При выполнении задания токен OIDC предоставляется поставщику облачных служб. Чтобы проверить токен, поставщик облачных служб проверяет, соответствуют ли субъект и другие утверждения токена OIDC условиям, предварительно заданным в определении доверия OIDC облачной роли.

В приведенном ниже примере в токене OIDC используется субъект (sub), который ссылается на среду задания с именем prod в репозитории octo-org/octo-repo.

{
  "typ": "JWT",
  "alg": "RS256",
  "x5t": "example-thumbprint",
  "kid": "example-key-id"
}
{
  "jti": "example-id",
  "sub": "repo:octo-org/octo-repo:environment:prod",
  "environment": "prod",
  "aud": "https://github.com/octo-org",
  "ref": "refs/heads/main",
  "sha": "example-sha",
  "repository": "octo-org/octo-repo",
  "repository_owner": "octo-org",
  "actor_id": "12",
  "repository_visibility": "private",
  "repository_id": "74",
  "repository_owner_id": "65",
  "run_id": "example-run-id",
  "run_number": "10",
  "run_attempt": "2",
  "runner_environment": "github-hosted",
  "actor": "octocat",
  "workflow": "example-workflow",
  "head_ref": "",
  "base_ref": "",
  "event_name": "workflow_dispatch",
  "repo_property_workspace_id": "ws-abc123",
  "ref_type": "branch",
  "job_workflow_ref": "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main",
  "iss": "https://token.actions.githubusercontent.com",
  "nbf": 1632492967,
  "exp": 1632493867,
  "iat": 1632493567
}

Проверка подлинности пользовательских действий с помощью OIDC

Пользовательские действия используют getIDToken() метод из набора средств Actions или curl команды для проверки подлинности с помощью OIDC.

Дополнительные сведения см. в разделе Справочник по OpenID Connect.

Изменение рабочих процессов для использования OIDC

Рабочие процессы GitHub Actions могут использовать маркеры OIDC вместо секретов для проверки подлинности с помощью поставщиков облачных служб. Многие популярные поставщики облачных служб предлагают официальные действия входа, упрощающие процесс использования OIDC в рабочих процессах. Дополнительные сведения об обновлении рабочих процессов с определенными поставщиками облачных служб см. в разделе Усиление безопасности развертываний.

Использование пользовательских свойств репозитория как OIDC утверждает

Примечание.

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

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

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

Необходимые условия

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

Добавление пользовательского свойства к заявкам на токены OIDC

Чтобы включить пользовательское свойство в OIDC-токены, используйте REST API или интерфейс настроек для вашей организации или предприятия.

          **Используя интерфейс настроек:** Перейдите на страницу настроек Actions OIDC вашей организации или предприятия, чтобы посмотреть и управлять, какие пользовательские свойства включены в токены OIDC.

Скриншот настроек OIDC для организации или предприятия.

  •         **Использование REST API:** Отправьте `POST` запрос на добавление пользовательского свойства к заявкам на токены OIDC для вашей организации:

Пример токена OIDC с пользовательским свойством

В следующем примере показан токен OIDC, включающий пользовательское workspace_id свойство:

{
  "sub": "repo:my-org/my-repo:ref:refs/heads/main",
  "aud": "https://github.com/my-org",
  "repository": "my-org/my-repo",
  "repo_property_workspace_id": "ws-abc123"
}

Вы можете использовать repo_property_* претензии из условий доверия вашего облачного провайдера для создания гибких политик контроля доступа на основе атрибутов. Дополнительные сведения см. в разделе Справочник по OpenID Connect.

Поддержка OIDC для Dependabot

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

Dependabot поддерживает аутентификацию OIDC для любого типа реестра, использующего аутентификацию username и password, когда реестр размещён на AWS CodeArtifact, Azure DevOps Artifacts или JFrog Artifactory.

Преимущества аутентификации OIDC для Dependabot заключаются:

  •         **Усиленная безопасность:** Устраняет статичные, долгоживущие учетные данные из ваших репозиториев.

  •         **Более простое управление:** Обеспечивает безопасный, соответствующий политикам доступ к частным реестрам.

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

Дополнительные сведения см. в разделе Настройка доступа к частным реестрам для Dependabot.

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

Дополнительные сведения о настройке OIDC см. в разделе Усиление безопасности развертываний.

Справочные сведения об OIDC см. в разделе Справочник по OpenID Connect.