{"meta":{"title":"Verwenden von OpenID Connect mit wiederverwendbaren Workflows","intro":"Du kannst wiederverwendbare Workflows mit OIDC verwenden, um Ihre Bereitstellungsschritte zu standardisieren und abzusichern.","product":"GitHub Actions","breadcrumbs":[{"href":"/de/actions","title":"GitHub Actions"},{"href":"/de/actions/how-tos","title":"Anleitungen"},{"href":"/de/actions/how-tos/secure-your-work","title":"Schütze deine Arbeit"},{"href":"/de/actions/how-tos/secure-your-work/security-harden-deployments","title":"Sicherheitshärtungen bei Bereitstellungen"},{"href":"/de/actions/how-tos/secure-your-work/security-harden-deployments/oidc-with-reusable-workflows","title":"OIDC mit wiederverwendbaren Workflows"}],"documentType":"article"},"body":"# Verwenden von OpenID Connect mit wiederverwendbaren Workflows\n\nDu kannst wiederverwendbare Workflows mit OIDC verwenden, um Ihre Bereitstellungsschritte zu standardisieren und abzusichern.\n\n## Informationen zu wiederverwendbaren Workflows\n\nAnstatt 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 [Wiederverwenden von Workflows](/de/actions/using-workflows/reusing-workflows#access-to-reusable-workflows) beschriebenen Zugriffsanforderungen erfüllt.\n\nDu solltest mit den Konzepten vertraut sein, die unter [Wiederverwenden von Workflows](/de/actions/using-workflows/reusing-workflows) und [OpenID Connect](/de/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect) beschrieben werden.\n\n## Definieren der Vertrauensbedingungen\n\nWenn 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:\n\n* **Verwenden von `job_workflow_ref`:**\n  * Um Vertrauensbedingungen auf der Grundlage wiederverwendbarer Workflows zu erstellen, muss dein Cloudanbieter benutzerdefinierte Ansprüche für `job_workflow_ref` unterstützen. Dadurch kann dein Cloudanbieter identifizieren, von welchem Repository der Auftrag ursprünglich stammt.\n  * Für Clouds, die nur die Standardansprüche (Zielgruppe (`aud`) und Antragsteller (`sub`)) unterstützen, kannst du die API verwenden, um den Anspruch `sub` so anzupassen, dass er `job_workflow_ref` enthält. Weitere Informationen finden Sie unter [OpenID Connect](/de/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#customizing-the-token-claims). Unterstützung für benutzerdefinierte Ansprüche ist derzeit für Google Cloud Platform und HashiCorp Vault verfügbar.\n\n* **Anpassen der Tokenansprüche**:\n  * Sie können differenziertere Vertrauensbedingungen konfigurieren, indem Sie die Angaben anpassen zu Ansprüchen des Antragstellers (`sub`) der enthalten ist im JWT. Weitere Informationen finden Sie unter [OpenID Connect](/de/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#customizing-the-token-claims).\n\n## Funktionsweise des Tokens mit wiederverwendbaren Workflows\n\nWä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 `job_workflow_ref`, der Informationen zum aufgerufenen Workflow enthält.\n\nDas folgende OIDC-Token ist beispielsweise für einen Auftrag konzipiert, der Teil eines aufgerufenen Workflows war.\n`workflow`, `ref` und andere Attribute beschreiben den aufrufenden Workflow, während `job_workflow_ref` sich auf den aufgerufenen Workflow bezieht:\n\n```yaml copy\n{\n  \"typ\": \"JWT\",\n  \"alg\": \"RS256\",\n  \"x5t\": \"example-thumbprint\",\n  \"kid\": \"example-key-id\"\n}\n{\n  \"jti\": \"example-id\",\n  \"sub\": \"repo:octo-org/octo-repo:environment:prod\",\n  \"aud\": \"https://github.com/octo-org\",\n  \"ref\": \"refs/heads/main\",\n  \"sha\": \"example-sha\",\n  \"repository\": \"octo-org/octo-repo\",\n  \"repository_owner\": \"octo-org\",\n  \"actor_id\": \"12\",\n  \"repository_id\": \"74\",\n  \"repository_owner_id\": \"65\",\n  \"run_id\": \"example-run-id\",\n  \"run_number\": \"10\",\n  \"run_attempt\": \"2\",\n  \"actor\": \"octocat\",\n  \"workflow\": \"example-workflow\",\n  \"head_ref\": \"\",\n  \"base_ref\": \"\",\n  \"event_name\": \"workflow_dispatch\",\n  \"ref_type\": \"branch\",\n  \"job_workflow_ref\": \"octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main\",\n  \"iss\": \"https://token.actions.githubusercontent.com\",\n  \"nbf\": 1632492967,\n  \"exp\": 1632493867,\n  \"iat\": 1632493567\n}\n```\n\nWenn 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.\n\n## Beispiele\n\n**Filtern nach wiederverwendbaren Workflows innerhalb eines bestimmten Repositorys**\n\nDu 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 `octo-org/octo-automation` und in jedem Repository im Besitz der Organisation `octo-org` definiert ist.\n\n* **Antragsteller:**\n  * Syntax: `repo:ORG_NAME/*`\n  * Beispiel: `repo:octo-org/*`\n\n* **Benutzerdefinierter Anspruch:**\n  * Syntax: `job_workflow_ref:ORG_NAME/REPO_NAME`\n  * Beispiel: `job_workflow_ref:octo-org/octo-automation@*`\n\n**Filtern nach einem bestimmten wiederverwendbaren Workflow in einem bestimmten Verweis**\n\nDu 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 `octo-org/octo-automation/.github/workflows/deployment.yml` und in jedem Repository im Besitz der Organisation `octo-org` definiert ist.\n\n* **Antragsteller:**\n  * Syntax: `repo:ORG_NAME/*`\n  * Beispiel: `repo:octo-org/*`\n\n* **Benutzerdefinierter Anspruch:**\n  * Syntax: `job_workflow_ref:ORG_NAME/REPO_NAME/.github/workflows/WORKFLOW_FILE@ref`\n  * Beispiel: `job_workflow_ref:octo-org/octo-automation/.github/workflows/deployment.yml@ 10040c56a8c0253d69db7c1f26a0d227275512e2`"}