Обзор OpenID Connect (OIDC)
GitHub Actions рабочие процессы часто предназначены для доступа к облачному провайдеру (такому как AWS, Azure, GCP, HashiCorp Vault и другим) с целью развертывания программного обеспечения или использования облачных сервисов. Прежде чем рабочий процесс сможет получить доступ к ресурсам, он должен предоставить поставщику облачных служб учетные данные, например пароль или токен. Эти учетные данные обычно хранятся в виде секрета в GitHub, и рабочий процесс каждый раз при запуске предоставляет этот секрет облачному провайдеру.
Однако использование жёстко закодированных секретов требует создания учетных данных в облачном провайдере, а затем дублирования GitHub их в виде секрета.
После установки подключения доверия с поставщиком облачных служб, поддерживающим OIDC, можно настроить рабочий процесс для запроса маркера доступа с коротким сроком действия непосредственно от поставщика облачных служб.
Преимущества использования OIDC
Изменив рабочие процессы для использования токенов OIDC, можно реализовать указанные ниже рекомендации по обеспечению безопасности.
-
**Никаких секретов облаков:** Вам не придётся дублировать облачные учетные данные как долгоживущие GitHub секреты. Вместо этого можно настроить отношение доверия к OIDC в системе поставщика облачных служб, а затем изменить рабочие процессы для запроса кратковременного маркера доступа у поставщика облачных служб через OIDC. -
**Управление проверкой подлинности и авторизацией**. Вы получаете более детальный контроль над использованием учетных данных рабочими процессами и можете применять средства проверки подлинности и авторизации поставщика облачных служб для управления доступом к облачным ресурсам. -
**Смена учетных данных**. При использовании OIDC поставщик облачных служб выдает кратковременный маркер доступа, который действителен только для одного задания, после чего его действие автоматически истекает.
Как OIDC интегрируется с GitHub Actions
Следующая схема показывает, как GitHubпровайдер OIDC интегрируется с вашими рабочими процессами и облачным провайдером:
- Вы устанавливаете доверительные отношения OIDC в облачном провайдере, позволяя конкретным GitHub рабочим процессам запрашивать токены доступа в облаке от имени определённой облачной роли.
- Каждый раз, когда ваша задача запускается, GitHubпровайдер OIDC от A автоматически генерирует токен OIDC. Этот токен содержит несколько утверждений для надежной и проверяемой идентификации рабочего процесса, который пытается пройти проверку подлинности.
- Шаг или действие в задании workflow может запросить токен у GitHubOIDC-провайдера , который затем может быть представлен облачному провайдеру в качестве доказательства идентификации рабочего процесса.
- После того как поставщик облачных служб успешно проверит утверждения, представленные в токене, он предоставит кратковременный маркер доступа к облаку, который действует только в течение выполнения задания.
Основные сведения о токене 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://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 в рабочих процессах. Дополнительные сведения об обновлении рабочих процессов с определенными поставщиками облачных служб см. в разделе [AUTOTITLE](/actions/how-tos/security-for-github-actions/security-hardening-your-deployments).
Использование пользовательских свойств репозитория как OIDC утверждает
Администраторы организаций и предприятий могут включать пользовательские свойства репозитория в качестве заявок в токены OIDC. Это позволяет использовать политики контроля доступа на основе атрибутов (ABAC) в вашем облачном провайдере, реестре артефактов или менеджере секретов, которые управляются метаданными репозитория, а не жёстко записанными списками разрешений.
Как работают индивидуальные претензии на имущество
Сквозной поток для использования пользовательских свойств как OIDC-утверждений следующий:
-
**Определите пользовательские свойства.** Администратор организации или предприятия создаёт пользовательские свойства (например, `business_unit`, `data_classification`, или `environment_tier`) и присваивает значения репозиториям. Дополнительные сведения см. в разделе [AUTOTITLE и [AUTOTITLE](/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization)](/actions/reference/security/oidc#including-repository-custom-properties-in-oidc-tokens). -
**Включите свойства в токенах OIDC.** Администратор организации или предприятия выбирает, какие пользовательские свойства должны быть включены в токены OIDC, используя интерфейс настроек или REST API. -
**Претензии появляются автоматически.** Каждый рабочий процесс, запущенный в репозитории с установленным значением для включённого свойства, будет включать это значение в свой OIDC-токен с префиксом `repo_property_`. Изменения конфигурации на уровне рабочего процесса не требуются. -
**Обновите политики облачного доверия.** Вы обновляете условия доверия вашего облачного провайдера, чтобы оценить новые `repo_property_*` претензии, позволяя принимать детализированные решения доступа на основе атрибутов.
Поскольку это основано на GitHubсуществующей модели кратковременных учётных данных OIDC, долгоживущие секреты не требуются, и каждый токен ограничен, подлежит аудиту и автоматически ротируется для каждого запуска рабочего процесса.
Необходимые условия
- Пользовательские свойства должны быть уже определены на уровне организации или предприятия. Дополнительные сведения см. в разделе Управление настраиваемыми свойствами для репозиториев в организации.
- Вы должны быть администратором организации или корпоративного администратора.
Добавление пользовательского свойства к заявкам на токены OIDC
Чтобы включить пользовательское свойство в OIDC-токены, используйте REST API или интерфейс настроек для вашей организации или предприятия.
-
**Используя интерфейс настроек:** Перейдите на страницу настроек Actions OIDC вашей организации или предприятия, чтобы посмотреть и управлять, какие пользовательские свойства включены в токены OIDC. -
**Использование REST API:** Отправьте `POST` запрос на `/orgs/{org}/actions/oidc/customization/properties/repo` конечную точку с просьбой добавить пользовательское свойство в заявки на токены OIDC для вашей организации. Для получения параметров запроса и полной информации см. документацию REST API для управления пользовательскими свойствами OIDC: [AUTOTITLE](/rest/actions/oidc).
Пример токена OIDC с пользовательскими свойствами
В следующем примере показан токен OIDC, включающий два пользовательских свойства: свойство business_unit одиночного выбора и свойство строки workspace_id. Каждое пользовательское свойство появляется в токене с префиксом repo_property_ .
{
"sub": "repo:my-org/my-repo:ref:refs/heads/main",
"aud": "https://github.com/my-org",
"repository": "my-org/my-repo",
"repository_owner": "my-org",
"ref": "refs/heads/main",
"repo_property_business_unit": "payments",
"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.