{"meta":{"title":"OpenID Connect","intro":"OpenID Connect позволяет рабочим процессам обмениваться маркерами краткосрочного действия непосредственно из поставщика облачных служб.","product":"GitHub Actions","breadcrumbs":[{"href":"/ru/actions","title":"GitHub Actions"},{"href":"/ru/actions/concepts","title":"Основные понятия"},{"href":"/ru/actions/concepts/security","title":"Безопасность"},{"href":"/ru/actions/concepts/security/openid-connect","title":"OpenID Connect"}],"documentType":"article"},"body":"# OpenID Connect\n\nOpenID Connect позволяет рабочим процессам обмениваться маркерами краткосрочного действия непосредственно из поставщика облачных служб.\n\n## Обзор OpenID Connect (OIDC)\n\nGitHub Actions рабочие процессы часто предназначены для доступа к облачному провайдеру (такому как AWS, Azure, GCP, HashiCorp Vault и другим) с целью развертывания программного обеспечения или использования облачных сервисов. Прежде чем рабочий процесс сможет получить доступ к ресурсам, он должен предоставить поставщику облачных служб учетные данные, например пароль или токен. Эти учетные данные обычно хранятся в виде секрета в GitHub, и рабочий процесс каждый раз при запуске предоставляет этот секрет облачному провайдеру.\n\nОднако использование жёстко закодированных секретов требует создания учетных данных в облачном провайдере, а затем дублирования GitHub их в виде секрета.\n\nПосле установки подключения доверия с поставщиком облачных служб, поддерживающим OIDC, можно настроить рабочий процесс для запроса маркера доступа с коротким сроком действия непосредственно от поставщика облачных служб.\n\n## Преимущества использования OIDC\n\nИзменив рабочие процессы для использования токенов OIDC, можно реализовать указанные ниже рекомендации по обеспечению безопасности.\n\n* **Никаких секретов облаков:** Вам не придётся дублировать облачные учетные данные как долгоживущие GitHub секреты. Вместо этого можно настроить отношение доверия к OIDC в системе поставщика облачных служб, а затем изменить рабочие процессы для запроса кратковременного маркера доступа у поставщика облачных служб через OIDC.\n* **Управление проверкой подлинности и авторизацией**. Вы получаете более детальный контроль над использованием учетных данных рабочими процессами и можете применять средства проверки подлинности и авторизации поставщика облачных служб для управления доступом к облачным ресурсам.\n* **Смена учетных данных**. При использовании OIDC поставщик облачных служб выдает кратковременный маркер доступа, который действителен только для одного задания, после чего его действие автоматически истекает.\n\n## Как OIDC интегрируется с GitHub Actions\n\nСледующая схема показывает, как GitHubпровайдер OIDC интегрируется с вашими рабочими процессами и облачным провайдером:\n\n![Схема интеграции поставщика облачных служб с GitHub Actions с помощью маркеров доступа и идентификаторов облачных ролей веб-токена JSON.](/assets/images/help/actions/oidc-architecture.png)\n\n1. Вы устанавливаете доверительные отношения OIDC в облачном провайдере, позволяя конкретным GitHub рабочим процессам запрашивать токены доступа в облаке от имени определённой облачной роли.\n2. Каждый раз, когда ваша задача запускается, GitHubпровайдер OIDC от A автоматически генерирует токен OIDC. Этот токен содержит несколько утверждений для надежной и проверяемой идентификации рабочего процесса, который пытается пройти проверку подлинности.\n3. Шаг или действие в задании workflow может запросить токен у GitHubOIDC-провайдера , который затем может быть представлен облачному провайдеру в качестве доказательства идентификации рабочего процесса.\n4. После того как поставщик облачных служб успешно проверит утверждения, представленные в токене, он предоставит кратковременный маркер доступа к облаку, который действует только в течение выполнения задания.\n\n## Основные сведения о токене OIDC\n\nКаждая задача запрашивает OIDC-токен у GitHubOIDC-провайдера , который отвечает автоматически сгенерированным JSON-веб-токеном (JWT), уникальным для каждой задачи рабочего процесса, где он генерируется. При выполнении задания токен OIDC предоставляется поставщику облачных служб. Чтобы проверить токен, поставщик облачных служб проверяет, соответствуют ли субъект и другие утверждения токена OIDC условиям, предварительно заданным в определении доверия OIDC облачной роли.\n\nВ приведенном ниже примере в токене OIDC используется субъект (`sub`), который ссылается на среду задания с именем `prod` в репозитории `octo-org/octo-repo`.\n\n```yaml\n{\n  \"typ\": \"JWT\",\n  \"alg\": \"RS256\",\n  \"x5t\": \"example-thumbprint\",\n  \"kid\": \"example-key-id\"\n}\n{\n  \"jti\": \"example-id\",\n  \"sub\": \"repo:octo-org/octo-repo:environment:prod\",\n  \"environment\": \"prod\",\n  \"aud\": \"https://github.com/octo-org\",\n  \"ref\": \"refs/heads/main\",\n  \"sha\": \"example-sha\",\n  \"repository\": \"octo-org/octo-repo\",\n  \"repository_owner\": \"octo-org\",\n  \"actor_id\": \"12\",\n  \"repository_visibility\": \"private\",\n  \"repository_id\": \"74\",\n  \"repository_owner_id\": \"65\",\n  \"run_id\": \"example-run-id\",\n  \"run_number\": \"10\",\n  \"run_attempt\": \"2\",\n  \"runner_environment\": \"github-hosted\",\n  \"actor\": \"octocat\",\n  \"workflow\": \"example-workflow\",\n  \"head_ref\": \"\",\n  \"base_ref\": \"\",\n  \"event_name\": \"workflow_dispatch\",\n  \"repo_property_workspace_id\": \"ws-abc123\",\n  \"ref_type\": \"branch\",\n  \"job_workflow_ref\": \"octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main\",\n  \"iss\": \"https://token.actions.githubusercontent.com\",\n  \"nbf\": 1632492967,\n  \"exp\": 1632493867,\n  \"iat\": 1632493567\n}\n```\n\n> \\[!NOTE]\n> Утверждение `sub` в этом примере использует предыдущий формат. Репозитории, созданные после 15 июля 2026 г., используют неизменяемый формат темы по умолчанию, включающий идентификаторы владельца и репозитория (недоступные для GitHub Enterprise Server). Дополнительные сведения см. в разделе [Справочник по OpenID Connect](/ru/actions/reference/security/oidc#immutable-subject-claims).\n\n## Проверка подлинности пользовательских действий с помощью OIDC\n\nПользовательские действия используют `getIDToken()` метод из набора средств Actions или `curl` команды для проверки подлинности с помощью OIDC.\n\nДополнительные сведения см. в разделе [Справочник по OpenID Connect](/ru/actions/reference/security/oidc#methods-for-requesting-the-oidc-token).\n\n## Изменение рабочих процессов для использования OIDC\n\nGitHub Actions рабочие процессы могут использовать токены OIDC вместо секретов для аутентификации с облачными провайдерами. Многие популярные поставщики облачных служб предлагают официальные действия входа, упрощающие процесс использования OIDC в рабочих процессах. Дополнительные сведения об обновлении рабочих процессов с определенными поставщиками облачных служб см. в разделе [Усиление безопасности развертываний](/ru/actions/how-tos/secure-your-work/security-harden-deployments).\n\n## Использование пользовательских свойств репозитория как OIDC утверждает\n\nАдминистраторы организаций и предприятий могут включать пользовательские свойства репозитория в качестве заявок в токены OIDC. Это позволяет использовать политики контроля доступа на основе атрибутов (ABAC) в вашем облачном провайдере, реестре артефактов или менеджере секретов, которые управляются метаданными репозитория, а не жёстко записанными списками разрешений.\n\n### Как работают индивидуальные претензии на имущество\n\nСквозной поток для использования пользовательских свойств как OIDC-утверждений следующий:\n\n1. **Определите пользовательские свойства.** Администратор организации или предприятия создаёт пользовательские свойства (например, `business_unit`, `data_classification`, или `environment_tier`) и присваивает значения репозиториям. Дополнительные сведения см. в разделе \\[AUTOTITLE и [Управление настраиваемыми свойствами для репозиториев в организации](/ru/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization)]\\(/actions/reference/security/oidc#including-repository-custom-properties-in-oidc-tokens).\n2. **Включите свойства в токенах OIDC.** Администратор организации или предприятия выбирает, какие пользовательские свойства должны быть включены в токены OIDC, используя интерфейс настроек или REST API.\n3. **Претензии появляются автоматически.** Каждый рабочий процесс, запущенный в репозитории с установленным значением для включённого свойства, будет включать это значение в свой OIDC-токен с префиксом `repo_property_`. Изменения конфигурации на уровне рабочего процесса не требуются.\n4. **Обновите политики облачного доверия.** Вы обновляете условия доверия вашего облачного провайдера, чтобы оценить новые `repo_property_*` претензии, позволяя принимать детализированные решения доступа на основе атрибутов.\n\nПоскольку это основано на GitHubсуществующей модели кратковременных учётных данных OIDC, долгоживущие секреты не требуются, и каждый токен ограничен, подлежит аудиту и автоматически ротируется для каждого запуска рабочего процесса.\n\n### Необходимые условия\n\n* Пользовательские свойства должны быть уже определены на уровне организации или предприятия. Дополнительные сведения см. в разделе [Управление настраиваемыми свойствами для репозиториев в организации](/ru/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization).\n* Вы должны быть администратором организации или корпоративного администратора.\n\n### Добавление пользовательского свойства к заявкам на токены OIDC\n\nЧтобы включить пользовательское свойство в OIDC-токены, используйте REST API или интерфейс настроек для вашей организации или предприятия.\n\n* **Используя интерфейс настроек:** Перейдите на страницу настроек Actions OIDC вашей организации или предприятия, чтобы посмотреть и управлять, какие пользовательские свойства включены в токены OIDC.\n\n* **Использование REST API:** Отправьте `POST` запрос на `/orgs/{org}/actions/oidc/customization/properties/repo` конечную точку с просьбой добавить пользовательское свойство в заявки на токены OIDC для вашей организации. Для получения параметров запроса и полной информации см. документацию REST API для управления пользовательскими свойствами OIDC: [REST API endpoints для GitHub Actions OIDC](/ru/rest/actions/oidc).\n\n### Пример токена OIDC с пользовательскими свойствами\n\nВ следующем примере показан токен OIDC, включающий два пользовательских свойства: свойство `business_unit` одиночного выбора и свойство строки `workspace_id`. Каждое пользовательское свойство появляется в токене с префиксом `repo_property_` .\n\n```json\n{\n  \"sub\": \"repo:my-org/my-repo:ref:refs/heads/main\",\n  \"aud\": \"https://github.com/my-org\",\n  \"repository\": \"my-org/my-repo\",\n  \"repository_owner\": \"my-org\",\n  \"ref\": \"refs/heads/main\",\n  \"repo_property_business_unit\": \"payments\",\n  \"repo_property_workspace_id\": \"ws-abc123\"\n}\n```\n\nВы можете использовать `repo_property_*` претензии из условий доверия вашего облачного провайдера для создания гибких политик контроля доступа на основе атрибутов. Для получения дополнительной информации о формате претензий, поддерживаемых типах свойств и ограничениях см. [Справочник по OpenID Connect](/ru/actions/reference/security/oidc#including-repository-custom-properties-in-oidc-tokens).\n\n## Поддержка OIDC для Dependabot\n\nDependabot может использовать OIDC для аутентификации с частными реестрами, исключая необходимость хранить долгоживущие учетные данные как секреты репозитория. С помощью аутентификации на основе OIDC задания Dependabot обновления могут динамически получать краткосрочные учетные данные от вашего облачного идентификатора.\n\nDependabot поддерживает аутентификацию OIDC для любого типа реестра, который использует `username` аутентификацию `password` , когда реестр размещён на AWS CodeArtifact, Azure DevOps Artifacts или JFrog Artifactory.\n\nПреимущества аутентификации OIDC для Dependabot :\n\n* **Усиленная безопасность:** Устраняет статичные, долгоживущие учетные данные из ваших репозиториев.\n* **Более простое управление:** Обеспечивает безопасный, соответствующий политикам доступ к частным реестрам.\n* **Избегайте ограничения тарифов:** Динамические учетные данные помогают избежать достижения лимитов скорости, связанных со статическими токенами.\n\nДополнительные сведения см. в разделе [Настройка доступа к частным реестрам для Dependabot](/ru/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries#using-oidc-for-authentication).\n\n## Следующие шаги\n\nДополнительные сведения о настройке OIDC см. в разделе [Усиление безопасности развертываний](/ru/actions/how-tos/secure-your-work/security-harden-deployments).\n\nСправочные сведения об OIDC см. в разделе [Справочник по OpenID Connect](/ru/actions/reference/security/oidc)."}