Informationen zu wiederverwendbaren Workflows
Anstatt Bereitstellungsaufträge zu kopieren und von einem Workflow in einen anderen einzufügen, kannst du einen wiederverwendbaren Workflow erstellen, der die Bereitstellungsschritte ausführt. Ein wiederverwendbarer Workflow kann von einem anderen Workflow genutzt werden, wenn er eine der in AUTOTITLE beschriebenen Zugriffsanforderungen erfüllt.
Du solltest mit den Konzepten vertraut sein, die unter AUTOTITLE und AUTOTITLE beschrieben werden.
Definieren der Vertrauensbedingungen
Wenn du wiederverwendbare Workflows in Kombination mit OpenID Connect (OIDC) verwendest, kannst du konsistente Bereitstellungen in deinem Repository, deiner Organisation oder deinem Unternehmen erzwingen. Dies erreichst du durch das Definieren von Vertrauensbedingungen für Cloudrollen basierend auf wiederverwendbaren Workflows. Die verfügbaren Optionen variieren je nach verwendetem Cloudanbieter:
-
Verwenden von :
- Um Vertrauensbedingungen auf der Grundlage wiederverwendbarer Workflows zu erstellen, muss dein Cloudanbieter benutzerdefinierte Ansprüche für unterstützen. Dadurch kann dein Cloudanbieter identifizieren, von welchem Repository der Auftrag ursprünglich stammt.
- Für Clouds, die nur die Standardansprüche (Zielgruppe () und Antragsteller ()) unterstützen, kannst du die API verwenden, um den Anspruch so anzupassen, dass er enthält. Weitere Informationen finden Sie unter AUTOTITLE. Unterstützung für benutzerdefinierte Ansprüche ist derzeit für Google Cloud Platform und HashiCorp Vault verfügbar.
-
Anpassen der Tokenansprüche:
- Sie können differenziertere Vertrauensbedingungen konfigurieren, indem Sie die Angaben anpassen zu Ansprüchen des Antragstellers () der enthalten ist im JWT. Weitere Informationen finden Sie unter AUTOTITLE.
Funktionsweise des Tokens mit wiederverwendbaren Workflows
Während einer Workflow-Ausführung präsentiert der OIDC-Anbieter von GitHub dem Cloud-Anbieter ein OIDC-Token, das Informationen über den Job enthält. Wenn dieser Auftrag Teil eines wiederverwendbaren Workflows ist, enthält das Token die Standardansprüche, die Informationen zum aufrufenden Workflow enthalten. Außerdem umfasst es den benutzerdefinierten Anspruch , der Informationen zum aufgerufenen Workflow enthält.
Das folgende OIDC-Token ist beispielsweise für einen Auftrag konzipiert, der Teil eines aufgerufenen Workflows war. , und andere Attribute beschreiben den aufrufenden Workflow, während sich auf den aufgerufenen Workflow bezieht:
{
"typ": "JWT",
"alg": "RS256",
"x5t": "example-thumbprint",
"kid": "example-key-id"
}
{
"jti": "example-id",
"sub": "repo:octo-org/octo-repo:environment:prod",
"aud": "https://github.com/octo-org",
"ref": "refs/heads/main",
"sha": "example-sha",
"repository": "octo-org/octo-repo",
"repository_owner": "octo-org",
"actor_id": "12",
"repository_id": "74",
"repository_owner_id": "65",
"run_id": "example-run-id",
"run_number": "10",
"run_attempt": "2",
"actor": "octocat",
"workflow": "example-workflow",
"head_ref": "",
"base_ref": "",
"event_name": "workflow_dispatch",
"ref_type": "branch",
"job_workflow_ref": "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main",
"iss": "https://token.actions.githubusercontent.com",
"nbf": 1632492967,
"exp": 1632493867,
"iat": 1632493567
}
{
"typ": "JWT",
"alg": "RS256",
"x5t": "example-thumbprint",
"kid": "example-key-id"
}
{
"jti": "example-id",
"sub": "repo:octo-org/octo-repo:environment:prod",
"aud": "https://github.com/octo-org",
"ref": "refs/heads/main",
"sha": "example-sha",
"repository": "octo-org/octo-repo",
"repository_owner": "octo-org",
"actor_id": "12",
"repository_id": "74",
"repository_owner_id": "65",
"run_id": "example-run-id",
"run_number": "10",
"run_attempt": "2",
"actor": "octocat",
"workflow": "example-workflow",
"head_ref": "",
"base_ref": "",
"event_name": "workflow_dispatch",
"ref_type": "branch",
"job_workflow_ref": "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main",
"iss": "https://token.actions.githubusercontent.com",
"nbf": 1632492967,
"exp": 1632493867,
"iat": 1632493567
}
Wenn dein wiederverwendbarer Workflow Bereitstellungsschritte ausführt, benötigt er in der Regel Zugriff auf eine bestimmte Cloudrolle, und du musst allen Repositorys in deiner Organisation das Aufrufen dieses wiederverwendbaren Workflows erlauben. Erstelle hierzu die Vertrauensbedingung, die jedes Repository und jeden aufrufenden Workflow zulässt, und filtere dann nach der Organisation und dem aufgerufenen Workflow. Im nächsten Abschnitt findest du einige Beispiele.
Beispiele
Filtern nach wiederverwendbaren Workflows innerhalb eines bestimmten Repositorys
Du kannst einen benutzerdefinierten Anspruch konfigurieren, der nach jedem wiederverwendbaren Workflow in einem bestimmten Repository filtern kann. In diesem Beispiel muss die Workflowausführung von einem Auftrag stammen, der in einem wiederverwendbaren Workflow im Repository und in jedem Repository im Besitz der Organisation definiert ist.
-
Antragsteller:
- Syntax:
- Beispiel:
-
Benutzerdefinierter Anspruch:
- Syntax:
- Beispiel:
Filtern nach einem bestimmten wiederverwendbaren Workflow in einem bestimmten Verweis
Du kannst einen benutzerdefinierten Anspruch konfigurieren, der nach einem bestimmten wiederverwendbaren Workflow filtert. In diesem Beispiel muss die Workflowausführung von einem Auftrag stammen, der im wiederverwendbaren Workflow und in jedem Repository im Besitz der Organisation definiert ist.
-
Antragsteller:
- Syntax:
- Beispiel:
-
Benutzerdefinierter Anspruch:
- Syntax:
- Beispiel: