Примечание. В GitHub Enterprise Server в настоящее время не поддерживаются средства выполнения тестов, размещенные в GitHub. Дополнительные сведения о планируемой поддержке в будущем см. в GitHub public roadmap.
Сведения о многократно используемых рабочих процессах
Вместо копирования и вставки заданий развертывания из одного рабочего процесса в другой можно создать многократно используемый рабочий процесс, выполняющий шаги развертывания. Повторно используемый рабочий процесс может использоваться другим рабочим процессом, если он соответствует одному из требований к доступу, описанным в разделеПовторное использование рабочих процессов.
Вы должны ознакомиться с понятиями, описанными в разделе[ "AUTOTITLE" иПовторное использование рабочих процессов](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect)".
Определение условий доверия
В сочетании с OpenID Connect (OIDC) многократно используемые рабочие процессы позволяют обеспечить согласованные развертывания в репозитории, организации или предприятии. Это можно сделать, определив условия доверия для облачных ролей на основе многократно используемых рабочих процессов. Доступные варианты зависят от поставщика облачных служб:
-
Использование
job_workflow_ref
.- Для создания условий доверия на основе многократно используемых рабочих процессов ваш поставщик облачных служб должен поддерживать пользовательские утверждения для
job_workflow_ref
. Это позволяет поставщику облачных служб определять, из какого репозитория изначально поступило задание. - Для облаков, поддерживающих только стандартные утверждения (аудитория (
aud
) и субъект (sub
)), можно использовать API для настройки утвержденияsub
, чтобы включитьjob_workflow_ref
. Дополнительные сведения см. в разделе "Сведения об усилении защиты с помощью OpenID Connect". Поддержка пользовательских утверждений в настоящее время доступна для Google Cloud Platform и HashiCorp Vault.
- Для создания условий доверия на основе многократно используемых рабочих процессов ваш поставщик облачных служб должен поддерживать пользовательские утверждения для
-
Настройка утверждений маркера.
- Вы можете настроить более детализированные условия доверия, настроив subject (
iss``sub
) claim — включено в JWT. Дополнительные сведения см. в разделе "Сведения об усилении защиты с помощью OpenID Connect".
- Вы можете настроить более детализированные условия доверия, настроив subject (
Как маркер работает с многократно используемыми рабочими процессами
Во время выполнения рабочего процесса поставщик OIDC GitHubпредставляет поставщику облачных служб маркер OIDC, который содержит сведения о задании. Если это задание является частью многократно используемого рабочего процесса, маркер будет включать стандартные утверждения, содержащие сведения о вызывающем рабочем процессе, а также пользовательское утверждение job_workflow_ref
, которое содержит сведения о вызываемом рабочем процессе.
Например, следующий маркер OIDC предназначен для задания, являющегося частью вызываемого рабочего процесса. Атрибуты workflow
, ref
и другие описывают вызывающий рабочий процесс, в то время как job_workflow_ref
ссылается на вызываемый рабочий процесс:
{ "typ": "JWT", "alg": "RS256", "x5t": "example-thumbprint", "kid": "example-key-id" } { "jti": "example-id", "sub": "repo:octo-org/octo-repo: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_id": "74", "repository_owner_id": "65", "run_id": "example-run-id", "run_number": "10", "run_attempt": "2", "actor": "octocat", "workflow": "example-workflow", "head_ref": "", "base_ref": "", "event_name": "workflow_dispatch", "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 }
{
"typ": "JWT",
"alg": "RS256",
"x5t": "example-thumbprint",
"kid": "example-key-id"
}
{
"jti": "example-id",
"sub": "repo:octo-org/octo-repo: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_id": "74",
"repository_owner_id": "65",
"run_id": "example-run-id",
"run_number": "10",
"run_attempt": "2",
"actor": "octocat",
"workflow": "example-workflow",
"head_ref": "",
"base_ref": "",
"event_name": "workflow_dispatch",
"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
}
Если многократно используемый рабочий процесс выполняет шаги развертывания, то ему обычно требуется доступ к определенной облачной роли, и вы можете захотеть разрешить любому репозиторию в организации вызывать этот многократно используемый рабочий процесс. Чтобы разрешить это, вам нужно создать условие доверия, которое разрешает любой репозиторий и любой вызывающий рабочий процесс, а затем выполнить фильтрацию по организации и вызываемому рабочему процессу. Некоторые примеры см. в следующем разделе.
Примеры
Фильтрация многократно используемых рабочих процессов в определенном репозитории
Вы можете настроить пользовательское утверждение, которое фильтрует любой многократно используемый рабочий процесс в определенном репозитории. В этом примере выполнение рабочего процесса должно запускаться из задания, определенного в многократно используемом рабочем процессе в репозитории octo-org/octo-automation
, и в любом репозитории, принадлежащем организации octo-org
.
-
Тема:
- Синтаксис:
repo:ORG_NAME/*
- Пример:
repo:octo-org/*
- Синтаксис:
-
Пользовательское утверждение:
- Синтаксис:
job_workflow_ref:ORG_NAME/REPO_NAME
- Пример:
job_workflow_ref:octo-org/octo-automation@*
- Синтаксис:
Фильтрация конкретного многократно используемого рабочего процессов по определенной ссылке
Вы можете настроить пользовательское утверждение, которое фильтрует определенный многократно используемый рабочий процесс. В этом примере выполнение рабочего процесса должно запускаться из задания, определенного в многократно используемом рабочем процессе octo-org/octo-automation/.github/workflows/deployment.yml
, и в любом репозитории, принадлежащем организации octo-org
.
-
Тема:
- Синтаксис:
repo:ORG_NAME/*
- Пример:
repo:octo-org/*
- Синтаксис:
-
Пользовательское утверждение:
- Синтаксис:
job_workflow_ref:ORG_NAME/REPO_NAME/.github/workflows/WORKFLOW_FILE@ref
- Пример:
job_workflow_ref:octo-org/octo-automation/.github/workflows/deployment.yml@ 10040c56a8c0253d69db7c1f26a0d227275512e2
- Синтаксис: