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

Используйте GitHub Apps для автоматизации защиты развертываний с помощью сторонних систем.

Кто может использовать эту функцию?

Custom deployment protection rules are available in public repositories for all plans. For access to custom deployment protection rules in private or internal repositories, you must use GitHub Enterprise. For more information, see GitHub’s plans.

В этой статье

Note

Пользовательские правила защиты развертывания в настоящее время находятся в public preview и подвергаются изменению.

Сведения о правилах защиты пользовательских развертываний

Вы можете включить собственные правила защиты для шлюза развертываний с помощью сторонних служб. Например, можно использовать такие службы, как Datadog, Honeycomb и ServiceNow, чтобы предоставить автоматические утверждения для развертываний в GitHub.

Пользовательские правила защиты развертывания основаны на GitHub Apps и выполняются на основе веб-перехватчиков и обратных вызовов. Утверждение или отклонение задания рабочего процесса основано на использовании deployment_protection_rule веб-перехватчика. Дополнительные сведения см. в разделе События и полезные данные веб-перехватчика и утверждение или отклонение развертываний.

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

Использование пользовательских правил защиты развертывания для утверждения или отклонения развертываний

Развертывания в среде могут быть утверждены или отклонены на основе условий, определенных в любой внешней службе, такой как утвержденный билет в системе УПРАВЛЕНИЯ ИТ-службами (ITSM), уязвимый результат сканирования на зависимости или стабильные метрики работоспособности облачного ресурса. Решение об утверждении или отклонении развертываний осуществляется по усмотрению интеграции стороннего приложения и условий, которые вы определяете в них. Ниже приведены несколько вариантов использования, для которых можно создать правило защиты развертывания.

  • ITSM & Security Operations: вы можете проверить готовность службы, проверяя качество, безопасность и соответствие процессам, которые проверяют готовность к развертыванию.
  • Системы наблюдения: вы можете проконсультироваться с системами мониторинга или наблюдаемости (системы управления производительностью активов и агрегатами журналов, системами проверки работоспособности облачных ресурсов и т. д.) для проверки готовности к безопасности и развертыванию.
  • Средства качества кода и тестирования: вы можете проверить наличие автоматических тестов на сборках CI, которые необходимо развернуть в среде.

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

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

  1. Создайте GitHub App. Дополнительные сведения см. в разделе Регистрация приложения GitHub. Настройте GitHub App следующим образом.

    1. При необходимости в текстовом поле URL-адреса обратного вызова в разделе "Идентификация и авторизация пользователей" введите URL-адрес обратного вызова. Дополнительные сведения см. в разделе Сведения о URL-адресе обратного вызова авторизации пользователя.
    2. В разделе "Разрешения" выберите разрешения репозитория.
    3. Справа от пункта "Действия", щелкните раскрывающееся меню и выберите Access: Только для чтения.
      Снимок экрана: раздел "Разрешения репозитория" при создании нового приложения GitHub. Кнопка настройки разрешений с выбранным разрешением "только для чтения" для действий выделена темно-оранжевым прямоугольником.
    4. Справа от пункта "Развертывания", щелкните раскрывающееся меню и выберите Access: Чтение и запись.
      Снимок экрана: параметры разрешений "Развертывания" в разделе "Разрешения репозитория" при создании нового приложения GitHub. Кнопка для настройки разрешений с выбранным разрешением "только для чтения" для развертываний выделена темно-оранжевым прямоугольником.
    5. В разделе "Подписка на события" выберите правило защиты развертывания.
      Снимок экрана: раздел "Подписка на события" при создании нового приложения GitHub. Флажок для подписки на событие правила защиты развертывания выделен темно-оранжевым прямоугольником.

  2. Установите настраиваемое правило защиты развертывания в репозиториях и включите его для использования. Дополнительные сведения см. в разделе Настройка пользовательских правил защиты развертывания.

Утверждение или отклонение развертываний

Когда рабочий процесс достигнет задания, ссылающегося на среду с включенным пользовательским правилом защиты развертывания, GitHub отправляет POST запрос на URL-адрес, который настроен, содержащий deployment_protection_rule полезные данные. Вы можете написать правило защиты развертывания, чтобы автоматически отправлять запросы REST API, утверждающие или отклоняющие развертывание на основе полезных deployment_protection_rule данных. Настройте запросы REST API следующим образом.

  1. Проверьте входящий POST запрос. Дополнительные сведения см. в разделе Проверка доставки веб-перехватчика.

  2. Используйте веб-маркер JSON для проверки подлинности в виде GitHub App. Дополнительные сведения см. в разделе Проверка подлинности в качестве приложения GitHub.

  3. Используя идентификатор установки из полезных deployment_protection_rule данных веб-перехватчика, создайте маркер установки. Дополнительные сведения см. в разделе Сведения о проверке подлинности с помощью приложения GitHub.

    curl --request POST \
--url "https://api.github.com/app/installations/INSTALLATION_ID/ACCESS_TOKENS" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer {jwt}" \
--header "Content-Type: application/json" \
--data \
'{ \
   "repository_ids": [321], \
   "permissions": { \
      "deployments": "write" \
   } \
}'

  4. При необходимости, чтобы добавить отчет о состоянии, не выполняя никаких других действий в GitHub, отправьте POST запрос /repos/OWNER/REPO/actions/runs/RUN_ID/deployment_protection_ruleв . В тексте запроса опустите stateэлемент . Дополнительные сведения см. в разделе Конечные точки REST API для выполнения рабочих процессов. Отчет о состоянии можно опубликовать в одном развертывании до 10 раз. Отчеты о состоянии поддерживают форматирование Markdown и могут содержать до 1024 символов.

  5. Чтобы утвердить или отклонить запрос, отправьте POST запрос /repos/OWNER/REPO/actions/runs/RUN_ID/deployment_protection_ruleв . В тексте запроса задайте state для свойства значение approved или rejected. Дополнительные сведения см. в разделе Конечные точки REST API для выполнения рабочих процессов.

  6. При необходимости запросите состояние утверждения рабочего процесса, отправив GET запрос /repos/OWNER/REPOSITORY_ID/actions/runs/RUN_ID/approvalsв . Дополнительные сведения см. в разделе Конечные точки REST API для выполнения рабочих процессов.

  7. При необходимости просмотрите развертывание на GitHub. Дополнительные сведения см. в разделе Проверка развертываний.

Публикация правил защиты пользовательского развертывания в GitHub Marketplace

Вы можете опубликовать GitHub App в GitHub Marketplace, чтобы разработчики могли обнаруживать подходящие правила защиты и устанавливать их в репозиториях GitHub . Вы также можете просмотреть существующие правила защиты развертывания в соответствии с вашими потребностями. Дополнительные сведения см. в разделе [AUTOTITLE и Сведения о GitHub Marketplace для приложений](/apps/publishing-apps-to-github-marketplace/listing-an-app-on-github-marketplace).