Skip to main content

Esta versión de GitHub Enterprise Server se discontinuó el 2024-03-26. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener rendimiento mejorado, seguridad mejorada y nuevas características, actualice a la versión más reciente de GitHub Enterprise Server. Para obtener ayuda con la actualización, póngase en contacto con el soporte técnico de GitHub Enterprise.

Asignar permisos a los jobs

Modifica los permisos predeterminados concedidos a GITHUB_TOKEN.

Nota: Actualmente los ejecutores hospedados en GitHub no se admiten en GitHub Enterprise Server. Puede ver más información sobre la compatibilidad futura planeada en GitHub public roadmap.

Información general

Puede usar permissions para modificar los permisos predeterminados concedidos a GITHUB_TOKEN si se agrega o elimina el acceso según sea necesario, de forma que solo se permita el acceso mínimo necesario. Para obtener más información, vea «Autenticación automática de tokens».

Puede utilizar permissions ya sea como una clave de nivel superior, para aplicarlos a todos los trabajos en el flujo de trabajo, o en los trabajos específicos. Cuando agrega la clave permissions en un trabajo específico, todas las acciones y comandos de ejecución dentro de este que utilicen GITHUB_TOKEN obtendrán los derechos de acceso que especifique. Para más información, vea jobs.<job_id>.permissions.

En cada uno de los ámbitos disponibles, que se muestran en la tabla siguiente, puedes asignar uno de los permisos: read, writeo none. Si especifica el acceso para cualquiera de estos ámbitos, todos los que no se especifiquen se establecen en none.

Los ámbitos y detalles disponibles de lo que cada uno permite que una acción haga:

ÁmbitoPermite que una acción que usa GITHUB_TOKEN
actionsTrabajar con Acciones de GitHub. Por ejemplo, actions: write permite que una acción cancele la ejecución de un flujo de trabajo. Para obtener más información, vea «Permisos que requieren las Github Apps».
checksTrabajar con ejecuciones de comprobación y conjuntos de comprobación. Por ejemplo, checks: write permite que una acción cancele la ejecución de una comprobación. Para obtener más información, vea «Permisos que requieren las Github Apps».
contentsTrabajar con el contenido del repositorio. Por ejemplo, contents: read permite que una acción enumere las confirmaciones, mientras que contents:write permita que la acción cree una versión. Para obtener más información, vea «Permisos que requieren las Github Apps».
deploymentsTrabajar con implementaciones. Por ejemplo, deployments: write permite que una acción cree una implementación. Para obtener más información, vea «Permisos que requieren las Github Apps».
discussionsTrabajar con GitHub Discussions. Por ejemplo, discussions: write permite que una acción cierre o elimine una discusión. Para obtener más información, vea «Utilizar la API de GraphQL para los debates».
issuesTrabajar con problemas. Por ejemplo, issues: write permite que una acción agregue un comentario a un problema. Para obtener más información, vea «Permisos que requieren las Github Apps».
packagesTrabajar con GitHub Packages. Por ejemplo, packages: write permite que una acción cargue y publique paquetes en GitHub Packages. Para obtener más información, vea «Acerca de los permisos para los Paquetes de GitHub».
pagesTrabajar con GitHub Pages. Por ejemplo, pages: write permite que una acción solicite una compilación de GitHub Pages. Para obtener más información, vea «Permisos que requieren las Github Apps».
pull-requestsTrabajar con solicitudes de incorporación de cambios. Por ejemplo, pull-requests: write permite que una acción agregue una etiqueta a una solicitud de incorporación de cambios. Para obtener más información, vea «Permisos que requieren las Github Apps».
repository-projectsTrabajar con proyectos de GitHub (clásico). Por ejemplo, repository-projects: write permite que una acción agregue una columna a un proyecto (clásico). Para obtener más información, vea «Permisos que requieren las Github Apps».
security-eventsTrabajar con el análisis de código de GitHub y las alertas de Dependabot. Por ejemplo, security-events: read permite que una acción enumere las alertas de Dependabot para el repositorio, mientras que security-events: write permite que una acción actualice el estado de una alerta de análisis de código. Para más información, consulta "Permisos de repositorio para "Alertas de examen de código"" y "Permisos de repositorio para "alertas de Dependabot"" en "Permisos necesarios para las aplicaciones de GitHub".
statusesTrabajar con estados de confirmación. Por ejemplo, statuses:read permite que una acción enumere los estados de confirmación de una referencia determinada. Para obtener más información, vea «Permisos que requieren las Github Apps».

Definición del acceso para los ámbitos de GITHUB_TOKEN

Para definir el acceso que GITHUB_TOKEN permitirá, especifica read, write o none como valor de los ámbitos disponibles en la clave permissions.

permissions:
  actions: read|write|none
  checks: read|write|none
  contents: read|write|none
  deployments: read|write|none
  issues: read|write|none
  discussions: read|write|none
  packages: read|write|none
  pages: read|write|none
  pull-requests: read|write|none
  repository-projects: read|write|none
  security-events: read|write|none
  statuses: read|write|none

Si especifica el acceso para cualquiera de estos ámbitos, todos los que no se especifiquen se establecen en none.

Puede utilizar la siguiente sintaxis para definir un acceso read-all o write-all para todos los alcances disponibles:

permissions: read-all
permissions: write-all

Puedes utilizar la siguiente sintaxis para inhabilitar los permisos para todos los alcances disponibles:

permissions: {}

Cambio de los permisos en un repositorio bifurcado

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 GitHub Actions. Para obtener más información, vea «Administrar los ajustes de las GitHub Actions de un repositorio».

Establecimiento de los permisos de GITHUB_TOKEN para todos los trabajos de un flujo de trabajo

Puede especificar permissions en el nivel superior de un flujo de trabajo para que el valor se aplique a todos los trabajos del flujo de trabajo.

Ejemplo: establecimiento de los permisos de GITHUB_TOKEN para un flujo de trabajo completo

En este ejemplo se muestran los permisos que se están configurando para GITHUB_TOKEN que aplicará a todos los trabajos en el flujo de trabajo. Se otorga acceso de lectura a todos los permisos.

name: "My workflow"

on: [ push ]

permissions: read-all

jobs:
  ...

Establecimiento de los permisos de GITHUB_TOKEN para un trabajo concreto

Para un trabajo concreto, puede usar jobs.<job_id>.permissions para modificar los permisos predeterminados concedidos a GITHUB_TOKEN si se agrega o elimina el acceso según sea necesario, de forma que solo se permita el acceso mínimo necesario. Para obtener más información, vea «Autenticación automática de tokens».

Al especificar el permiso dentro de una definición de trabajo, puede configurar un conjunto diferente de permisos para el GITHUB_TOKEN de cada trabajo, si es necesario. Como alternativa, puedes especificar los permisos para todos los jobs en el flujo de trabajo. Para obtener información sobre cómo definir permisos en el nivel de flujo de trabajo, vea permissions.

Ejemplo: establecimiento de los permisos de GITHUB_TOKEN para un trabajo en un flujo de trabajo

En este ejemplo se muestran los permisos establecidos para GITHUB_TOKEN que solo se aplicarán al trabajo denominado stale. Se concede acceso de escritura a los ámbitos issues y pull-requests. El resto de los alcances no tendrán acceso.

jobs:
  stale:
    runs-on: ubuntu-latest

    permissions:
      issues: write
      pull-requests: write

    steps:
      - uses: actions/stale@v5