Примечание. В GitHub Enterprise Server в настоящее время не поддерживаются средства выполнения тестов, размещенные в GitHub. Дополнительные сведения о планируемой поддержке в будущем см. в GitHub public roadmap.
Обзор
OpenID Connect (OIDC) позволяет рабочим процессам GitHub Actions получать доступ к ресурсам в Amazon Web Services (AWS) без необходимости хранить учетные данные AWS в виде долгоживущих секретов GitHub.
В этом руководстве рассказывается, как в AWS настроить доверие к OIDC GitHub в качестве федеративного удостоверения, а также есть пример рабочего процесса для действия aws-actions/configure-aws-credentials
, в котором для проверки подлинности в AWS и доступа к ресурсам используются маркеры.
Предварительные требования
-
Основные понятия о том, как GitHub использует OpenID Connect (OIDC), а также его архитектуру и преимущества, см. в разделе Сведения об усилении защиты с помощью OpenID Connect.
-
Прежде чем продолжить, необходимо спланировать стратегию безопасности, чтобы обеспечить выдачу маркеров доступа только предсказуемым способом. Чтобы управлять тем, как поставщик облачных служб выдает маркеры доступа, необходимо определить по крайней мере одно условие, запретив недоверенным репозиториям запрашивать маркеры доступа к облачным ресурсам. Дополнительные сведения см. в разделе Сведения об усилении защиты с помощью OpenID Connect.
Добавление поставщика удостоверений в AWS
Сведения о добавлении поставщика OIDC GitHub в IAM см. в документации по AWS.
- Для URL-адреса поставщика: укажите
https://HOSTNAME/_services/token
- Для аудитории: укажите
sts.amazonaws.com
, если используете официальное действие.
Настройка роли и политики доверия
Сведения о настройке роли и доверия в IAM см. в документации по AWS в разделе "Получение роли" и "Создание роли для веб-удостоверения или федерации OpenID Connect".
Измените политику доверия, чтобы добавить поле sub
в условия проверки. Пример:
"Condition": {
"StringEquals": {
"HOSTNAME/_services/token:aud": "sts.amazonaws.com",
"HOSTNAME/_services/token:sub": "repo:octo-org/octo-repo:ref:refs/heads/octo-branch"
}
}
В следующем примере StringLike
используется с оператором с подстановочными знаками (*
), чтобы разрешить любой ветви, ветви слияния запросов на вытягивание или среде из octo-org/octo-repo
организации и репозитория взять на себя роль в AWS.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456123456:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:*"
},
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}
}
]
}
Обновление рабочего процесса GitHub Actions
Чтобы обновить рабочие процессы для OIDC, необходимо внести два изменения в YAML:
- Добавьте параметры разрешений для маркера.
- Используйте действие
aws-actions/configure-aws-credentials
для обмена маркера OIDC (JWT) на маркер доступа к облаку.
Добавление параметров разрешений
Для выполнения задания или рабочего процесса требуется параметр permissions
с id-token: write
. Вы не сможете запросить маркер идентификатора JWT OIDC, если permissions
для параметра id-token
задано read
или none
.
Этот параметр id-token: write
позволяет запрашивать JWT у поставщика OIDC GitHub, применяя один из следующих способов:
- использование переменных среды в средстве выполнения (
ACTIONS_ID_TOKEN_REQUEST_URL
иACTIONS_ID_TOKEN_REQUEST_TOKEN
); - использование
getIDToken()
из набора средств Actions.
Если необходимо получить токен OIDC для рабочего процесса, разрешение можно установить на уровне рабочего процесса. Пример:
permissions:
id-token: write # This is required for requesting the JWT
contents: read # This is required for actions/checkout
Если необходимо получить маркер OIDC только для одного задания, такое разрешение можно установить в этом задании. Пример:
permissions:
id-token: write # This is required for requesting the JWT
В зависимости от требований рабочего процесса, возможно, будет необходимо указать здесь дополнительные разрешения.
Для повторно используемых рабочих процессов параметру для id-token
следует задать значение write
на уровне вызывающего рабочего процесса или в конкретном задании, permissions
которое вызывает повторно используемый рабочий процесс. Дополнительные сведения см. в разделе Повторное использование рабочих процессов.
Запрос маркера доступа
Действие aws-actions/configure-aws-credentials
получает JWT от поставщика OIDC GitHub, а затем запрашивает маркер доступа из AWS. Дополнительные сведения см. в документации по AWS.
<example-bucket-name>
: имя контейнера S3.<role-to-assume>
: вместо значения из примера укажите свою роль AWS.<example-aws-region>
: добавьте название своего региона AWS.
# Sample workflow to access AWS resources when workflow is tied to branch
# The workflow Creates static website using aws s3
name: AWS example workflow
on:
push
env:
BUCKET_NAME : "<example-bucket-name>"
AWS_REGION : "<example-aws-region>"
# permission can be added at job level or workflow level
permissions:
id-token: write # This is required for requesting the JWT
contents: read # This is required for actions/checkout
jobs:
S3PackageUpload:
runs-on: ubuntu-latest
steps:
- name: Git clone the repository
uses: actions/checkout@v3
- name: configure aws credentials
uses: aws-actions/configure-aws-credentials@v2
with:
role-to-assume: arn:aws:iam::1234567890:role/example-role
role-session-name: samplerolesession
aws-region: ${{ env.AWS_REGION }}
# Upload a file to AWS s3
- name: Copy index.html to s3
run: |
aws s3 cp ./index.html s3://${{ env.BUCKET_NAME }}/