Skip to main content

Erstellen von benutzerdefinierten Regeln für den Bereitstellungsschutz

Wer kann dieses Feature verwenden?

Benutzerdefinierte Regeln für den Bereitstellungsschutz sind in öffentlichen Repositorys für alle Pläne verfügbar. Für den Zugriff auf benutzerdefinierte Regeln für den Bereitstellungsschutz in privaten oder internen Repositorys musst du Enterprise verwenden. Weitere Informationen findest du unter -Pläne.

Hinweis

Benutzerdefinierte Regeln für den Bereitstellungsschutz befinden sich derzeit in der public preview. Änderungen sind vorbehalten.

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 zu ermöglichen.

Benutzerdefinierte Regeln für den Bereitstellungsschutz werden von 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.

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.

  1. Erstelle eine App. Weitere Informationen finden Sie unter Registrieren einer -App. Konfiguriere die 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 finden Sie 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.
      Screenshot: Abschnitt „Repository permissions“ für eine neue GitHub-App. Für die Berechtigung „Actions“ wird „Read-only“ angezeigt, und sie wird orange hervorgehoben.
    4. Klicke rechts neben „Bereitstellungen“ auf das Dropdownmenü und wähle Zugriff: Lesen und schreiben aus.
      Screenshot: Abschnitt „Repository permissions“ für eine neue GitHub-App. Für die Berechtigung „Deployments“ wird „Read and write“ angezeigt, und sie wird orange hervorgehoben.
    5. Wähle unter „Ereignisse abonnieren“ die Option Regel für Bereitstellungsschutz aus.
      Screenshot: Abschnitt „Subscribe to events section“ für eine neue GitHub-App. Das Kontrollkästchen für die Bereitstellungsschutzregel wird orange hervorgehoben.
  2. Installiere die benutzerdefinierte Bereitstellungsschutzregel in deinen Repositorys und aktiviere ihre Verwendung. Weitere Informationen finden Sie unter Konfigurieren von benutzerdefinierten Regeln für den Bereitstellungsschutz.

Sobald ein Workflow einen Auftrag erreicht, der auf eine Umgebung mit aktivierter benutzerdefinierter Bereitstellungsschutzregel verweist, sendet 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 finden Sie unter Validierung von Webhook-Zustellung.

  2. Verwende ein JSON-Webtoken zur Authentifizierung als App. Weitere Informationen finden Sie unter Authentifizieren als -App.

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

    curl --request POST \
    --url "https://api..com/app/installations/INSTALLATION_ID/ACCESS_TOKENS" \
    --header "Accept: application/vnd.+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 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 finden Sie 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 finden Sie 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 finden Sie unter REST-API-Endpunkte für Workflowausführungen.

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

Du kannst deine App im Marketplace veröffentlichen, um Entwickler*innen zu erlauben, geeignete Schutzregeln zu ermitteln und in ihren -Repositorys zu installieren. Alternativ dazu kannst du die vorhandenen benutzerdefinierten Regeln für den Bereitstellungsschutz durchsuchen, um für deine Anforderungen geeignete Regeln zu finden. Weitere Informationen findest du unter Informationen zu Marketplace für Apps und Listen einer App im Marketplace.