Creación de reglas de protección de implementación personalizadas

Acerca de las reglas de protección de implementación personalizadas

Puede habilitar sus propias reglas de protección personalizadas para controlar las implementaciones con servicios de terceros. Por ejemplo, puede usar servicios como Datadog, Honeycomb y ServiceNow para proporcionar aprobaciones automatizadas para implementaciones en GitHub.

Las reglas de protección de implementación personalizadas tienen tecnología de GitHub Apps y se ejecutan en función de webhooks y devoluciones de llamada. La aprobación o el rechazo de un trabajo de flujo de trabajo se basa en el consumo del webhook deployment_protection_rule. Para obtener más información, consulta "Eventos y cargas de webhook" y "Aprobación o rechazo de implementaciones".

Cuando hayas creado una regla de protección de implementación personalizada y la hayas instalado en el repositorio, la regla de protección de implementación personalizada estará disponible automáticamente para todos los entornos del repositorio.

Uso de reglas de protección de implementación personalizadas para aprobar o rechazar implementaciones

Las implementaciones en un entorno se pueden aprobar o rechazar en función de las condiciones definidas en cualquier servicio externo, como un vale aprobado en un sistema de administración de servicios de TI (ITSM), el resultado del examen vulnerable en las dependencias o las métricas de estado estables de un recurso en la nube. La decisión de aprobar o rechazar implementaciones es a discreción de la integración de la aplicación de terceros y las condiciones de acceso que defina en ellas. A continuación se muestran algunos casos de uso para los que puedes crear una regla de protección de implementación.

• ITSM & Operaciones de seguridad: puedes comprobar la preparación del servicio validando los procesos de calidad, seguridad y cumplimiento que comprueban la preparación de la implementación.
• Sistemas de observabilidad: puedes consultar sistemas de supervisión o observabilidad (sistemas de administración de rendimiento de recursos y agregadores de registro, sistemas de verificación de estado de recursos en la nube, etc.) para comprobar la seguridad y la preparación de la implementación.
• Herramientas de prueba y de calidad del código: puedes comprobar si hay pruebas automatizadas en compilaciones de CI que deben implementarse en un entorno.

Como alternativa, puedes escribir tus propias reglas de protección para cualquiera de los casos de uso anteriores o puedes definir cualquier lógica personalizada para aprobar o rechazar de forma segura las implementaciones de preproducción a entornos de producción.

Creación de una regla de protección de implementación personalizada con GitHub Apps

1. Crea un GitHub App. Para obtener más información, vea «Registro de una instancia de GitHub App». Configura los datos de GitHub App como se indica a continuación.

   1. Opcionalmente, en el campo de texto URL de devolución de llamada en "Identificación y autorización de usuarios", escribe la dirección URL de devolución de llamada. Para obtener más información, vea «Acerca de la dirección URL de devolución de llamada de autorización de usuario».
   2. En "Permisos", selecciona Permisos de repositorio.
   3. A la derecha de "Acciones", haz clic en el menú desplegable y selecciona Acceso: Solo lectura.
      
   4. A la derecha de "Implementaciones", haz clic en el menú desplegable y selecciona Acceso: Lectura y escritura.
      
   5. En "Suscribirse a eventos", selecciona Regla de protección de implementación.
      

2. Instala la regla de protección de implementación personalizada en los repositorios y habilítala para su uso. Para obtener más información, vea «Configuración de reglas de protección de implementación personalizadas».

Aprobación o rechazo de implementaciones

Una vez que un flujo de trabajo alcanza un trabajo que hace referencia a un entorno que tiene habilitada la regla de protección de implementación personalizada, GitHub envía una solicitud POST a una dirección URL que configura que contiene la carga útil deployment_protection_rule. Puedes escribir la regla de protección de implementación para enviar automáticamente solicitudes de API REST que aprueben o rechacen la implementación en función de la carga deployment_protection_rule. Configura las solicitudes de la API REST de la siguiente manera.

1. Valida la solicitud entrante POST. Para obtener más información, vea «Validación de entregas de webhook».

2. Usa un JSON Web Token para autenticarte como GitHub App. Para obtener más información, vea «Autenticarse como una GitHub App».

3. Con el identificador de instalación de la carga del webhook deployment_protection_rule, genera un token de instalación. Para obtener más información, vea «Acerca de la autenticación con una aplicación de GitHub».

   curl --request POST \
   --url "http(s)://HOSTNAME/api/v3/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. Opcionalmente, para agregar un informe de estado sin realizar ninguna otra acción a GitHub, envía una solicitud POST a /repos/OWNER/REPO/actions/runs/RUN_ID/deployment_protection_rule. En el cuerpo de la solicitud, omite el state Para obtener más información, vea «Puntos de conexión de API de REST para ejecuciones de flujo de trabajo». Puedes publicar un informe de estado en la misma implementación hasta 10 veces. Los informes de estado admiten el formato Markdown y pueden tener hasta 1024 caracteres de longitud.

5. Para aprobar o rechazar una solicitud, envía una solicitud POST a /repos/OWNER/REPO/actions/runs/RUN_ID/deployment_protection_rule. En el cuerpo de la solicitud, establece la propiedad state en approved o rejected. Para obtener más información, vea «Puntos de conexión de API de REST para ejecuciones de flujo de trabajo».

6. Opcionalmente, solicita el estado de una aprobación para una ejecución de flujo de trabajo mediante el envío de una solicitud GET a /repos/OWNER/REPOSITORY_ID/actions/runs/RUN_ID/approvals. Para obtener más información, vea «Puntos de conexión de API de REST para ejecuciones de flujo de trabajo».

7. Opcionalmente, revisa la implementación en GitHub. Para obtener más información, vea «Revisar los despliegues».