Autenticación automática de tokens

Al inicio de cada trabajo del flujo de trabajo, crea automáticamente un secreto _TOKEN único para usarlo en el flujo de trabajo. Puede usar _TOKEN para autenticarse en el trabajo del flujo.

Cuando habilitas Actions, instala una App en tu repositorio. El secreto _TOKEN es un token de acceso de instalación de App. Puedes usar el token de acceso de instalación para autenticarte en nombre de la App instalado en tu repositorio. Los permisos del token están limitados al repositorio que contiene tu flujo de trabajo. Para más información, consulta Permisos para _TOKEN.

Antes de que comience cada job, extrae un token de acceso de instalación para éste. _TOKEN expira cuando finaliza un trabajo o después de un máximo de 24 horas.

El token también está disponible en el contexto .token. Para más información, consulta Accessing contextual information about workflow runs.

Puedes usar _TOKEN mediante la sintaxis estándar para hacer referencia a secretos: ${{ secrets._TOKEN }}. Los ejemplos de uso de _TOKEN incluyen pasar el token como entrada a una acción, o bien utilizarlo para realizar una solicitud autenticada a la API de .

Al usar _TOKEN del repositorio para realizar tareas, los eventos desencadenados por _TOKEN, a excepción de workflow_dis y repository_dis, no crearán una ejecución de flujo de trabajo. Esto impide que crees ejecuciones de flujo de trabajo recursivas por accidente. Por ejemplo, si una ejecución de flujo de trabajo inserta código mediante _TOKEN del repositorio, un nuevo flujo de trabajo no se ejecutará incluso cuando el repositorio contenga un flujo de trabajo configurado para ejecutarse cuando se produzcan eventos push.

Las confirmaciones insertadas por un flujo de trabajo de Actions que usa _TOKEN no desencadenan una compilación de Pages.

En este flujo de trabajo de ejemplo se usa la CLI de , que necesita _TOKEN como valor para el parámetro de entrada GH_TOKEN:

name: Open new issue
on: workflow_dis

jobs:
  open-issue:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write
    steps:
      - run: |
          gh issue --repo ${{ .repository }} \
            create --title "Issue title" --body "Issue body"
        env:
          GH_TOKEN: ${{ secrets._TOKEN }}

name: Open new issue
on: workflow_dis

jobs:
  open-issue:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write
    steps:
      - run: |
          gh issue --repo ${{ .repository }} \
            create --title "Issue title" --body "Issue body"
        env:
          GH_TOKEN: ${{ secrets._TOKEN }}

Puede usar _TOKEN para realizar llamadas API autenticadas. Este flujo de trabajo de ejemplo crea una propuesta mediante la API REST del :

name: Create issue on commit

on: [ push ]

jobs:
  create_issue:
    runs-on: ubuntu-latest
    permissions:
      issues: write
    steps:
      - name: Create issue using REST API
        run: |
          curl --request POST \
          --url https://api..com/repos/${{ .repository }}/issues \
          --header 'authorization: Bearer ${{ secrets._TOKEN }}' \
          --header 'content-type: application/json' \
          --data '{
            "title": "Automated issue for commit: ${{ .sha }}",
            "body": "This issue was automatically created by the  Action workflow **${{ .workflow }}**. \n\n The commit hash was: _${{ .sha }}_."
            }' \
          --fail

Para obtener información sobre los puntos de conexión de la API a los que Apps puedes acceder con cada permiso, consulta Permisos que requieren las Apps.

En la tabla siguiente, se muestran los permisos concedidos al _TOKEN de manera predeterminada. Las personas con permisos administrativos en una empresa, organización o repositorio pueden configurar los permisos predeterminados para que sean permisivos o restringidos. Para obtener información sobre cómo establecer los permisos predeterminados para _TOKEN para tu empresa, organización o repositorio, consulta Requerir políticas para las Actions en tu empresa, Inhabilitar o limitar Actions para tu organización o Administrar los ajustes de las Actions de un repositorio.

Puede modificar los permisos de _TOKEN en archivos de flujo de trabajo individuales. Si los permisos predeterminados para _TOKEN son restrictivos, es posible que tenga que elevarlos para permitir que algunas acciones y comandos se ejecuten correctamente. Si los permisos predeterminados son permisivos, puede editar el archivo de flujo de trabajo para quitar algunos permisos de _TOKEN. Como práctica de seguridad recomendada, debe conceder el permiso de acceso menos necesario a _TOKEN.

Puede ver los permisos que ha tenido _TOKEN para un trabajo específico en la sección "Configuración del trabajo" del registro de ejecución de flujo de trabajo. Para más información, consulta Uso de registros de ejecución de flujo de trabajo.

También puede usar la clave permissions en el archivo de flujo de trabajo a fin de modificar los permisos para _TOKEN en un flujo de trabajo completo o en trabajos individuales. Esto te permite configurar los permisos mínimos requeridos para un flujo de trabajo o job.

Puede usar la clave permissions a fin de agregar y quitar permisos de lectura para repositorios bifurcados, pero normalmente no se puede conceder acceso de escritura. La excepción a este comportamiento es cuando un usuario administrador ha seleccionado la opción Enviar tokens a flujos de trabajo desde solicitudes de incorporación de cambios en la configuración de Actions. Para más información, consulta Administrar los ajustes de las Actions de un repositorio.

En los dos ejemplos de flujo de trabajo anteriores de este artículo se muestra la clave permissions que se usa en el nivel de trabajo, ya el procedimiento recomendado es limitar el ámbito de los permisos.

Para obtener detalles completos de la clave permissions, consulta Workflow syntax for Actions.

Los permisos para _TOKEN se establecen inicialmente con los valores predeterminados para la empresa, organización o repositorio. Si lo predeterminado se configura para los permisos restringidos en cualquiera de estos niveles, esto aplicará a los repositorios relevantes. Por ejemplo, si eliges las restricciones predeterminadas a nivel organizacional, entonces todos los repositorios de la organización utilizarán estos permisos restringidos como los predeterminados. Entonces, los permisos se ajustarán con base en cualquier configuración dentro del archivo de flujo de trabajo, primero a nivel del flujo de trabajo y luego al nivel de los jobs. Por último, si una solicitud de incorporación de cambios ha desencadenado el flujo de trabajo desde un repositorio bifurcado y no se selecciona el valor Enviar tokens de escritura a los flujos de trabajo desde las solicitudes de incorporación de cambios, los permisos se ajustarán para cambiar los de escritura a solo lectura.

Si necesitas un token que requiera permisos que no estén disponibles en _TOKEN, puedes crear una App y generar un token de acceso de instalación dentro del flujo de trabajo. Para más información, consulta Realización de solicitudes de API autenticadas con una aplicación de en un flujo de trabajo de Acciones de . Como alternativa, puedes crear un personal access token, almacenarlo como secreto en el repositorio y usar el token en el flujo de trabajo con la sintaxis ${{ secrets.SECRET_NAME }}. Para más información, consulta Administración de tokens de acceso personal y Uso de secretos en Acciones de .

• Límites de volumen de la API de REST