С помощью защиты выполнения рабочих процессов можно определить список разрешений, который управляет тем, кто может активировать GitHub Actions рабочие процессы и какие события разрешены для их выполнения. Для получения дополнительной информации см. О политиках Actions.
Примечание.
GitHub добавлена политика по умолчанию, которая блокирует pull_request_target событие в общедоступных репозиториях. Эта политика будет применена 2 ноября 2026 г. См . раздел AUTOTITLE.
Подготовка к добавлению защиты
Например, наборы правил, уровень защиты выполнения рабочего процесса с другими защитами в одном репозитории, организации или организации.
Вместо создания одной крупной политики для каждой учетной записи рекомендуется создавать несколько четко определенных политик и защиты слоев на разных уровнях учетных записей. Владельцы предприятий могут создавать защиту на уровне предприятия для широких неотговоримых политик. Затем владельцы и администраторы репозитория организации могут добавить эти ограничения.
Для каждой определяемой политики думайте:
-
Какие организации или репозитории будут нацелены на защиту. Например, открытый код репозитории могут потребовать более жестких ограничений на то, кто может активировать рабочие процессы. Репозитории можно использовать по таким факторам, как видимость, состояние развертывания или пользовательское свойство.
- Состояние развертывания происходит из организации linked artifacts page. Если это важный фактор, убедитесь, что вы отправляете записи развертывания при развертывании артефакта. См . раздел AUTOTITLE.
- Сведения о создании и назначении настраиваемых свойств см. в разделе Управление настраиваемыми свойствами для репозиториев в организации.
-
Какие рабочие процессы будут защищены. Например, рабочим процессам, которые развертывают рабочий код, может потребоваться определенный уровень защиты, но менее конфиденциальные автоматизации могут не нуждаться в том же уровне защиты. Политики можно ограничить определенными путями рабочего процесса или обязательными рабочими процессами.
-
Кто должен работать с этими рабочими процессами в репозиториях , на которые вы нацелены. Это могут быть пользователи с определенной ролью, выбранными учетными записями ботов или определенной командой. Рассмотрите возможность группировки этих пользователей в организации или корпоративной команде, чтобы их можно было легко связаться и ссылаться на них в нескольких наборах правил. См[. раздел AUTOTITLE или Создание группы организации](/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/create-enterprise-teams).
Создание политики выполнения рабочего процесса
Сначала создайте политику действий для уровня учетной записи, на который вы работаете.
В репозитории или организации:
- Перейдите на вкладку Параметры.
- В левой боковой панели, в разделе «Действия», нажмите «Политики».
В организации:
- Перейдите на вкладку "Политики ".
- На левой боковой панели щелкните "Действия", а затем "Политики".
Совет
Сведения о программном управлении политиками см. в разделе Конечные точки REST API для политик GitHub Actions.
Настройка политики
Затем создайте новую политику.
- Выберите имя политики.
- Выберите состояние принудительного применения. Если выбран параметр "Оценка " (GitHub Enterprise Cloud только), вы сможете отслеживать, когда пользователи получат ограничение в аналитике политики.
- Целевые рабочие процессы, организации или репозитории.
- Настройте следующие защиты выполнения рабочего процесса.
Ограничение субъектов
По умолчанию каждый пользователь с доступом к записи в репозиторий может запускать рабочие процессы. Акторские правила позволяют разделить, кто вносит код, от того, кто управляет вашим CI, поэтому вы можете предоставить участнику доступ к записи без возможности выполнять рабочие процессы.
Только разрешенные субъекты смогут запускать указанные рабочие процессы в целевом репозитории. Если вы также ограничиваете события, эти пользователи смогут активировать рабочие процессы только с разрешенными событиями. Не разрешенные субъекты не смогут выполнять указанные рабочие процессы вообще.
GitHub функции исключаются из этих ограничений для встроенных процессов, которые они выполняют GitHub Actions. Однако если вы создали рабочие процессы, которые должны выполняться удостоверением, связанным с GitHub функцией, например dependabot[bot], это удостоверение должно быть добавлено в качестве разрешенного субъекта.
Ограничение событий
Правила событий определяют, какие события разрешены, например push, pull_request, pull_request_targetи workflow_dispatch.
Оценка политик
Вы можете просмотреть аналитические сведения о политиках, чтобы просмотреть запуски рабочих процессов, которые были заблокированы (для активных политик) или были заблокированы (для политик оценки). Это хороший способ проверить, работают ли политики как предполагаемые и не вызывают ненужных трений.
Чтобы просмотреть аналитические сведения, щелкните страницу "Аналитика политик ". Вы найдете это прямо на странице GitHub Actions политик в репозитории, организации или корпоративной боковой панели.