Автоматическая проверка подлинности токенов

Сведения о секрете GITHUB_TOKEN

В начале запуска каждого рабочего процесса GitHub автоматически создает уникальный секрет GITHUB_TOKEN для использования в рабочем процессе. GITHUB_TOKEN можно использовать для проверки подлинности при выполнении рабочего процесса.

При включении GitHub Actions GitHub устанавливает GitHub App в репозитории. Секрет GITHUB_TOKEN — это маркер доступа установки GitHub App. Маркер доступа установки можно использовать для проверки подлинности от имени установленного в репозитории GitHub App. Разрешения маркера ограничены репозиторием, содержащим рабочий процесс. Дополнительные сведения см. в разделе «Разрешения дляGITHUB_TOKEN».

Перед началом выполнения каждого задания GitHub получает маркер доступа установки для задания. Срок действия GITHUB_TOKEN истекает при завершении задания или в течение не более 24 часов.

Маркер также доступен в контексте github.token. Дополнительные сведения см. в разделе Контексты.

Использование GITHUB_TOKEN в рабочем процессе

GITHUB_TOKEN можно использовать со стандартным синтаксисом для ссылки на секреты: ${{ secrets.GITHUB_TOKEN }}. К примерам использования GITHUB_TOKEN относятся передача маркера в качестве входных данных для действия или его использование для выполнения прошедшего проверку подлинности GitHub Enterprise Server запроса API.

Если вы выполняете задачи с помощью GITHUB_TOKEN репозитория, события, активированные GITHUB_TOKEN, не создадут новый запуск рабочего процесса. Это предотвращает случайное создание рекурсивных запусков рабочих процессов. Например, если при запуске рабочего процесса выполняется передача кода с помощью GITHUB_TOKEN репозитория, новый рабочий процесс не будет запущен, даже если репозиторий содержит рабочий процесс, настроенный для запуска при наступлении события push.

Пример 1. Передача GITHUB_TOKEN в качестве входных данных

В этом примере рабочего процесса используется действие маркировщика, для которого требуется GITHUB_TOKEN в качестве значения входного параметра repo-token:

name: Pull request labeler
on: [ pull_request_target ]

jobs:
  triage:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/labeler@v4
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}

Пример 2. Вызов REST API

GITHUB_TOKEN можно использовать для выполнения вызовов API, прошедших проверку подлинности. В этом примере рабочего процесса создается проблема с помощью REST API GitHub:

name: Create issue on commit

on: [ push ]

jobs:
  create_issue:
    runs-on: ubuntu-latest
    permissions:
      issues: write
    steps:
      - name: Create issue using REST API
        run: |
          curl --request POST \
          --url http(s)://HOSTNAME/api/v3/repos/${{ github.repository }}/issues \
          --header 'authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' \
          --header 'content-type: application/json' \
          --data '{
            "title": "Automated issue for commit: ${{ github.sha }}",
            "body": "This issue was automatically created by the GitHub Action workflow **${{ github.workflow }}**. \n\n The commit hash was: _${{ github.sha }}_."
            }' \
          --fail

Разрешения для GITHUB_TOKEN

Сведения о конечных точках API, к которым GitHub Apps может получить доступ с каждым разрешением, см. в разделе Разрешения, необходимые для приложений GitHub.

В следующей таблице показаны разрешения, предоставленные для GITHUB_TOKEN по умолчанию. Пользователи с разрешениями администратора для организации или репозитория могут задавать разрешения по умолчанию в качестве разрешительных или ограничительных. Сведения о том, как задать разрешения по умолчанию для GITHUB_TOKEN предприятия, организации или репозитория, см. в разделе Применение политик для GitHub Actions в вашем предприятии, Отключение или ограничение GitHub Actions для вашей организации или Управление параметрами GitHub Actions для репозитория.

Изменение разрешений для GITHUB_TOKEN

Разрешения для GITHUB_TOKEN можно изменить в отдельных файлах рабочего процесса. Если разрешения по умолчанию для GITHUB_TOKEN являются ограничительными, возможно, для успешного выполнения некоторых действий и команд потребуется повысить уровень разрешений. Если разрешения по умолчанию носят разрешительный характер, можно изменить файл рабочего процесса, удалив некоторые из разрешений для GITHUB_TOKEN. Из соображений безопасности рекомендуется предоставлять GITHUB_TOKEN минимальный необходимый доступ.

Посмотреть разрешения, выданные GITHUB_TOKEN для выполнения определенного задания, можно в разделе «Настройка задания» журнала выполнения рабочего процесса. Дополнительные сведения см. в разделе Использование журналов выполнения рабочих процессов.

Ключ permissions в файле рабочего процесса можно использовать для изменения разрешений GITHUB_TOKEN для всего рабочего процесса или отдельных заданий. Это позволяет настроить минимально необходимые разрешения для рабочего процесса или задания. При использовании ключа permissions для всех неуказанных разрешений доступ запрещен. Исключение составляет область metadata, которая всегда получает доступ на чтение.

С помощью ключа permissions можно добавлять и удалять разрешения на чтение для разветвленных репозиториев, но обычно предоставить доступ на запись нельзя. Исключением из этого поведения является то, что пользователь администратора выбрал Отправлять маркеры записи в рабочие процессы из запросов на вытягивание в параметрах GitHub Actions. Дополнительные сведения см. в разделе Управление параметрами GitHub Actions для репозитория.

В двух примерах рабочих процессов, приведенных выше в этой статье, показано использование ключа permissions на уровне рабочего процесса и на уровне задания. В примере 1 для всего рабочего процесса указаны два разрешения. В примере 2 доступ на запись предоставляется для одной области для одного задания.

Полные сведения о ключе см. в permissions разделе Синтаксис рабочего процесса для GitHub Actions.

Расчет разрешений для задания рабочего процесса

Изначально в качестве разрешений для GITHUB_TOKEN задаются параметры по умолчанию для предприятия, организации или репозитория. Если на любом из этих уровней по умолчанию заданы ограниченные разрешения, они будут применяться к соответствующим репозиториям. Например, если выбрать в качестве значения по умолчанию на уровне организации ограниченные разрешения, все репозитории в этой организации будут использовать в качестве значения по умолчанию ограниченные разрешения. Затем разрешения корректируются на основе любой конфигурации в файле рабочего процесса: сначала на уровне рабочего процесса, а затем на уровне задания. Наконец, если рабочий процесс был активирован запросом на вытягивание из разветвленного репозитория, а параметр Отправлять маркеры записи отправлять в рабочие процессы из запросов на вытягивание не выбран, разрешения корректируются, чтобы изменить любые разрешения на запись на разрешения только на чтение.

Предоставление дополнительных разрешений

Если вам нужен маркер, требующий разрешений, недоступных в GITHUB_TOKEN, можно создать GitHub App и создать маркер доступа к установке в рабочем процессе. Дополнительные сведения см. в разделе Выполнение запросов API с проверкой подлинности с помощью Приложение GitHub в рабочем процессе GitHub Actions. Кроме того, можно создать personal access token, сохранить его в качестве секрета в репозитории и использовать маркер в рабочей книге с синтаксисом ${{ secrets.SECRET_NAME }}. Дополнительные сведения см. в разделах Управление личными маркерами доступа и Зашифрованные секреты.

Дополнительные материалы

• "Ресурсы в REST API"