Erstellen von benutzerdefinierten Regeln für den Bereitstellungsschutz

Informationen zu benutzerdefinierten Regeln für den Bereitstellungsschutz

Du kannst deine eigenen benutzerdefinierten Regeln für den Bereitstellungsschutz aktivieren, um Bereitstellungen mit Drittanbieterdiensten zu schützen. Sie können z. B. Dienste wie Datadog, Honeycomb und ServiceNow verwenden, um automatisierte Genehmigungen für Bereitstellungen in GitHub zu ermöglichen.

Benutzerdefinierte Regeln für den Bereitstellungsschutz werden von GitHub Apps unterstützt und basierend auf Webhook und Rückrufen ausgeführt. Die Genehmigung oder Ablehnung eines Workflowauftrags basiert auf der Nutzung des deployment_protection_rule-Webhooks. Weitere Informationen findest du unter Webhook-Ereignisse und -Nutzlasten und Genehmigen oder Ablehnen von Bereitstellungen.

Nachdem du eine benutzerdefinierte Bereitstellungsschutzregel erstellt und in deinem Repository installiert hast, ist diese Regel automatisch für alle Umgebungen im Repository verfügbar.

Verwenden von benutzerdefinierten Bereitstellungsschutzregeln zum Genehmigen oder Ablehnen von Bereitstellungen

Bereitstellungen in einer Umgebung können basierend auf den in jedem externen Dienst definierten Bedingungen genehmigt oder abgelehnt werden, z. B. basierend auf genehmigten Tickets in einem ITSM-System (IT-Service-Management), Ergebnissen von Überprüfungen auf Sicherheitsrisiken bei Abhängigkeiten oder Integritätsmetriken einer Cloudressource. Die Entscheidung, Bereitstellungen zu genehmigen oder abzulehnen, liegt im Ermessen der integrierenden Drittanbieteranwendung und der darin definierten Schutzbedingungen. Im Folgenden findest du einige Anwendungsfälle, für die du eine Regel für den Bereitstellungsschutz erstellen kannst.

• ITSM & Security Operations: Du kannst die Dienstbereitschaft überprüfen, indem du Qualitäts-, Sicherheits- und Complianceprozesse validierst, die die Bereitstellungsbereitschaft verifizieren.
• Einblicksysteme: Du kannst Überwachungs- oder Einblicksysteme (Systeme zur Verwaltung der Ressourcenleistung und Protokollierungsaggregatoren, Systeme zur Überprüfung der Cloudressourcenintegrität usw.) konsultieren, um die Sicherheits- und Bereitstellungsbereitschaft zu überprüfen.
• Codequalität & Testtools: Du kannst in CI-Builds, die in einer Umgebung bereitgestellt werden müssen, nach automatisierten Tests suchen.

Alternativ dazu kannst du eigene Schutzregeln für jeden der oben genannten Anwendungsfälle schreiben oder benutzerdefinierte Logik definieren, um Bereitstellungen aus Vorproduktionsumgebungen in Produktionsumgebungen sicher zu genehmigen oder abzulehnen.

Erstellen einer benutzerdefinierten Regel für den Bereitstellungsschutz mit GitHub Apps

1. Erstelle eine GitHub App. Weitere Informationen findest du unter Registrieren einer GitHub-App. Konfiguriere die GitHub App wie folgt.

   1. Optional kannst du im Textfeld Rückruf-URL unter „Identifizieren und Autorisieren von Benutzern“ die Rückruf-URL eingeben. Weitere Informationen findest du unter Informationen zur Rückruf-URL für die Benutzerautorisierung.
   2. Wähle unter „Berechtigungen“ die Option Repositoryberechtigungen aus.
   3. Klicke rechts neben „Aktionen“ auf das Dropdownmenü und wähle Zugriff: Schreibgeschützt aus.
      
   4. Klicke rechts neben „Bereitstellungen“ auf das Dropdownmenü und wähle Zugriff: Lesen und schreiben aus.
      
   5. Wähle unter „Ereignisse abonnieren“ die Option Regel für Bereitstellungsschutz aus.
      

2. Installiere die benutzerdefinierte Bereitstellungsschutzregel in deinen Repositorys und aktiviere ihre Verwendung. Weitere Informationen findest du unter Konfigurieren von benutzerdefinierten Regeln für den Bereitstellungsschutz.

Genehmigen oder Ablehnen von Bereitstellungen

Sobald ein Workflow einen Auftrag erreicht, der auf eine Umgebung mit aktivierter benutzerdefinierter Bereitstellungsschutzregel verweist, sendet GitHub eine POST-Anforderung mit der Payload deployment_protection_rule an die von dir konfigurierte URL. Du kannst deine Bereitstellungsschutzregel so schreiben, dass automatisch REST-API-Anforderungen zum Genehmigen oder Ablehnen der Bereitstellung basierend auf der Payload deployment_protection_rule gesendet werden. Konfiguriere deine REST-API-Anforderungen wie folgt.

1. Validiere die eingehende POST-Anforderung. Weitere Informationen findest du unter Validierung von Webhook-Zustellung.

2. Verwende ein JSON-Webtoken zur Authentifizierung als GitHub App. Weitere Informationen findest du unter Authentifizieren als GitHub-App.

3. Generiere ein Installationstoken unter Verwendung der Installations-ID aus der Webhookpayload deployment_protection_rule. Weitere Informationen findest du unter Informationen zur Authentifizierung mit einer GitHub-App.

   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. Um einen Statusbericht hinzuzufügen, ohne weitere Aktionen auf GitHub auszuführen, können Sie optional eine POST-Anforderung an /repos/OWNER/REPO/actions/runs/RUN_ID/deployment_protection_rule senden. Lass im Anforderungstext den state weg. Weitere Informationen findest du unter REST-API-Endpunkte für Workflowausführungen. Du kannst einen Statusbericht bis zu zehn Mal an ein und dieselbe Bereitstellung posten. Statusberichte unterstützen die Markdownformatierung und können bis zu 1024 Zeichen lang sein.

5. Um eine Anforderung zu genehmigen oder abzulehnen, sende eine POST-Anforderung an /repos/OWNER/REPO/actions/runs/RUN_ID/deployment_protection_rule. Lege die Eigenschaft state im Anforderungstext entweder auf approved oder auf rejected fest. Weitere Informationen findest du unter REST-API-Endpunkte für Workflowausführungen.

6. Optional kannst du den Status einer Genehmigung für eine Workflowausführung anfordern, indem du eine GET-Anforderung an /repos/OWNER/REPOSITORY_ID/actions/runs/RUN_ID/approvals sendest. Weitere Informationen findest du unter REST-API-Endpunkte für Workflowausführungen.

7. Oder Sie sehen sich die Bereitstellung auf GitHub an. Weitere Informationen findest du unter Überprüfen von Bereitstellungen.