Примечание. В GitHub Enterprise Server в настоящее время не поддерживаются средства выполнения тестов, размещенные в GitHub. Дополнительные сведения о планируемой поддержке в будущем см. в GitHub public roadmap.
Обзор
OpenID Connect (OIDC) позволяет рабочим процессам GitHub Actions получать доступ к ресурсам в Azure без необходимости хранить учетные данные Azure в виде долговечных секретов GitHub.
В этом руководстве представлен обзор настройки Azure для доверия OIDC GitHub в качестве федеративного идентификатора, а также есть пример рабочего процесса для действия azure/login
, использующего токены для аутентификации в Azure и доступа к ресурсам.
Необходимые компоненты
-
Основные понятия о том, как GitHub использует OpenID Connect (OIDC) и его архитектуру и преимущества, см. в разделе "Сведения об усилении защиты с помощью OpenID Connect".
-
Прежде чем продолжить, необходимо спланировать стратегию безопасности, чтобы обеспечить выдачу маркеров доступа только предсказуемым способом. Чтобы управлять тем, как поставщик облачных служб выдает маркеры доступа, необходимо определить по крайней мере одно условие, запретив недоверенным репозиториям запрашивать маркеры доступа к облачным ресурсам. Дополнительные сведения см. в разделе Сведения об усилении защиты с помощью OpenID Connect.
-
Необходимо убедиться, что следующие конечные точки OIDC доступны поставщиком облачных служб:
https://HOSTNAME/_services/token/.well-known/openid-configuration
https://HOSTNAME/_services/token/.well-known/jwks
Примечание. Идентификатор Microsoft Entra (ранее известный как Azure AD) не имеет фиксированных диапазонов IP-адресов, определенных для этих конечных точек.
-
Убедитесь, что значение утверждения издателя, включенного в веб-токен JSON (JWT), имеет общедоступный url-адрес для routable. Дополнительные сведения см. в разделе Сведения об усилении защиты с помощью OpenID Connect.
Добавление федеративных учетных данных в Azure
Поставщик OIDC GitHub работает с федерацией идентификаторов рабочей нагрузки Azure. Обзор см. в документации Майкрософт в разделе Федерация идентификаторов рабочей нагрузки.
Чтобы настроить поставщик удостоверений OIDC в Azure, необходимо выполнить следующую конфигурацию. Инструкции по внесению этих изменений см. в документации Azure.
- Создайте приложение идентификатора записи и субъект-службу.
- Добавьте федеративные учетные данные для приложения Entra ID.
- Создайте секреты GitHub для хранения конфигурации Azure.
Дополнительное руководство по настройке поставщика удостоверений:
- Для обеспечения безопасности убедитесь, что вы рассмотрели "Сведения об усилении защиты с помощью OpenID Connect". Пример см. в разделе "Сведения об усилении защиты с помощью OpenID Connect".
- Для параметра
audience
рекомендуемое значениеapi://AzureADTokenExchange
, но здесь можно также указать другие значения.
Обновление рабочего процесса GitHub Actions
Чтобы обновить рабочие процессы для OIDC, необходимо внести два изменения в YAML:
- Добавьте параметры разрешений для маркера.
- Используйте действие
azure/login
для обмена маркера OIDC (JWT) на маркер доступа к облаку.
Примечание. Если среды используются в рабочих процессах или политиках OIDC, рекомендуется добавить правила защиты в среду для дополнительной безопасности. Например, можно настроить правила развертывания в среде, чтобы ограничить, какие ветви и теги могут развертываться в среде или получить доступ к секретам среды. Дополнительные сведения см. в разделе Управление средами для развертывания.
Добавление параметров разрешений
Для выполнения задания или рабочего процесса требуется permissions
параметр, позволяющий id-token: write
GitHubпоставщика OIDC для создания веб-маркера JSON для каждого запуска. Вы не сможете запросить маркер идентификатора JWT OIDC, если permissions
оно id-token
не задано write
, однако это значение не подразумевает предоставление доступа на запись к любым ресурсам, только возможность получить и задать маркер OIDC для действия или шага, чтобы включить проверку подлинности с помощью маркера доступа с коротким сроком действия. Любой фактический параметр доверия определяется с помощью утверждений OIDC, дополнительные сведения см. в разделе "Сведения об усилении защиты с помощью OpenID Connect".
Этот параметр 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
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
permissions:
id-token: write # This is required for requesting the JWT
Вам может потребоваться указать дополнительные разрешения в зависимости от требований рабочего процесса.
Для повторно используемых рабочих процессов, принадлежащих одному и тому же пользователю, организации или предприятиям, что и рабочий процесс вызывающего объекта, маркер OIDC, созданный в повторно используемый рабочий процесс, можно получить из контекста вызывающего объекта.
Для повторно используемых рабочих процессов за пределами организации или предприятия параметр id-token
должен быть явно задан write
на уровне рабочего процесса вызывающего объекта или permissions
в конкретном задании, которое вызывает повторно используемый рабочий процесс.
Это гарантирует, что маркер OIDC, созданный в повторно используемом рабочем процессе, может использоваться только в рабочих процессах вызывающего объекта.
Дополнительные сведения см. в разделе Повторное использование рабочих процессов.
Запрос маркера доступа
Действие azure/login
получает JWT от поставщика OIDC GitHub, а затем запрашивает маркер доступа из Azure. Дополнительные сведения см. в документации по azure/login
.
В следующем примере токен идентификатора OIDC обменивается с Azure для получения маркера доступа, который затем можно использовать для доступа к облачным ресурсам.
name: Run Azure Login with OIDC on: [push] permissions: id-token: write contents: read jobs: build-and-deploy: runs-on: ubuntu-latest steps: - name: 'Az CLI login' uses: azure/login@a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 with: client-id: ${{ secrets.AZURE_CLIENT_ID }} tenant-id: ${{ secrets.AZURE_TENANT_ID }} subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} - name: 'Run az commands' run: | az account show az group list
name: Run Azure Login with OIDC
on: [push]
permissions:
id-token: write
contents: read
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: 'Az CLI login'
uses: azure/login@a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- name: 'Run az commands'
run: |
az account show
az group list