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

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

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

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

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

Каждая задача запрашивает OIDC-токен у GitHubOIDC-провайдера , который отвечает автоматически сгенерированным JSON-веб-токеном (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://HOSTNAME/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",
  "enterprise": "avocado-corp",
  "enterprise_id": "2",
  "ref_type": "branch",
  "job_workflow_ref": "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main",
  "iss": "https://HOSTNAME/_services/token",
  "nbf": 1632492967,
  "exp": 1632493867,
  "iat": 1632493567
}

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

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

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

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

          GitHub Actions рабочие процессы могут использовать токены OIDC вместо секретов для аутентификации с облачными провайдерами. Многие популярные поставщики облачных служб предлагают официальные действия входа, упрощающие процесс использования OIDC в рабочих процессах. Дополнительные сведения об обновлении рабочих процессов с определенными поставщиками облачных служб см. в разделе [AUTOTITLE](/actions/how-tos/security-for-github-actions/security-hardening-your-deployments).

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

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

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

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

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

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

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

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

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

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

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