Note
Actualmente los ejecutores hospedados por GitHub no se admiten en GitHub Enterprise Server. Puede ver más información sobre la compatibilidad futura planeada en GitHub public roadmap.
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:
- Los nombres solo pueden contener caracteres alfanuméricos (
[a-z],[A-Z],[0-9]) o caracteres de subrayado (_). No se permiten espacios. - Los nombres no deben comenzar con el prefijo
GITHUB_. - Los nombres no deben comenzar con un número.
- Los nombres no distinguen mayúsculas de minúsculas.
- Los nombres deben ser únicos en el nivel en el que se hayan creado.
Si existe un secreto con el mismo nombre en varios niveles, tiene preferencia el del nivel más bajo. Por ejemplo, si un secreto a nivel de organización tiene el mismo nombre que un secreto a nivel de repositorio, entonces el secreto a nivel de repositorio tomará precedencia. 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
Si se ha usado un secreto en el trabajo, GitHub redacta automáticamente los secretos impresos en el registro. Debe evitar imprimir secretos en el registro intencionadamente.
Para los secretos almacenados a nivel organizacional, peudes utilizar las políticas de acceso para controlar qué repositorios pueden utilizar secretos organizacionales. Los secretos a nivel organizacional te permiten compartir secretos entre repositorios múltiples, lo cual reduce la necesidad de crear secretos duplicados. El actualizar un secreto de organización en una ubicación también garantiza que el cambio tome efecto en todos los flujos de trabajo del repositorio que lo utilicen.
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 Sintaxis del flujo de trabajo para 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 Realización de solicitudes de API autenticadas con una aplicación de GitHub en un flujo de trabajo de Acciones de GitHub.