About secrets
Secrets allow you to store sensitive information in your organization, repository, or repository environments. Secrets are variables that you create to use in GitHub Actions workflows in an organization, repository, or repository environment.
GitHub Actions can only read a secret if you explicitly include the secret in a workflow.
Naming your secrets
Tip
To help ensure that GitHub redacts your secrets in logs correctly, avoid using structured data as the values of secrets.
The following rules apply to secret names:
- Namen dürfen nur alphanumerische Zeichen (
[a-z],[A-Z],[0-9]) oder Unterstriche (_) enthalten. Leerzeichen sind nicht zulässig. - Namen dürfen nicht mit dem Präfix
GITHUB_beginnen. - Namen dürfen nicht mit einer Ziffer beginnen.
- Bei den Namen wird die Groß-/Kleinschreibung nicht berücksichtigt.
- Namen müssen auf der Ebene eindeutig sein, auf der sie erstellt werden.
Wenn ein Geheimnis mit demselben Namen auf mehreren Ebenen vorhanden ist, erhält das Geheimnis auf der niedrigsten Ebene Vorrang. Wenn beispielsweise ein Geheimnis auf Organisationsebene denselben Namen wie ein Geheimnis auf Repositoryebene aufweist, erhält das Geheimnis auf Repositoryebene Vorrang. Similarly, if an organization, repository, and environment all have a secret with the same name, the environment-level secret takes precedence.
Using your secrets in workflows
Warning
Wenn bei der Aufgabe ein Geheimnis verwendet wurde, werden von GitHub automatisch die in das Protokoll ausgegebenen Geheimnisse unkenntlich gemacht. Sie sollten die Geheimnisse nicht absichtlich in das Protokoll ausgeben.
Für Geheimnisse, die auf Organisationsebene gespeichert sind, kannst Du Zugriffsrichtlinien festlegen, um zu kontrollieren, welche Repositorys die Organisations-Geheimnisse verwenden können. Geheimnisse auf Organisationsebene ermöglichen es Dir, Geheimnisse zwischen mehreren Repositories zu teilen, was die Notwendigkeit zur Erstellung von doppelten Geheimnissen verringert. Die Aktualisierung eines Organisationsgeheimnisses an nur einem Ort stellt außerdem sicher, dass die Änderung in allen Workflows aller Repositorys wirksam wird, die dieses Geheimnis verwenden.
For environment secrets, you can enable required reviewers to control access to the secrets. A workflow job cannot access environment secrets until approval is granted by required approvers.
To make a secret available to an action, you must set the secret as an input or environment variable in your workflow file. Review the action's README file to learn about which inputs and environment variables the action expects. See Workflowsyntax für GitHub Actions.
Organization and repository secrets are read when a workflow run is queued, and environment secrets are read when a job referencing the environment starts.
Limiting credential permissions
When generating credentials, we recommend that you grant the minimum permissions possible. For example, instead of using personal credentials, use deploy keys or a service account. Consider granting read-only permissions if that's all that is needed, and limit access as much as possible.
When generating a personal access token (classic), select the fewest scopes necessary. When generating a fine-grained personal access token, select the minimum permissions and repository access required.
Instead of using a personal access token, consider using a GitHub App, which uses fine-grained permissions and short lived tokens, similar to a fine-grained personal access token. Unlike a personal access token, a GitHub App is not tied to a user, so the workflow will continue to work even if the user who installed the app leaves your organization. For more information, see Authentifizierte API-Anforderungen mit einer GitHub-App in einem GitHub Actions-Workflow.