Requerir políticas para las GitHub Actions en tu empresa

¿Cuáles son las directivas para GitHub Actions?

Las directivas empresariales controlan las opciones disponibles para los miembros de la empresa cuando utilizan GitHub Actions.

Si no aplica directivas empresariales, los propietarios de la organización y los usuarios con el permiso "Administrar directivas de acciones de la organización" tienen control total sobre GitHub Actions para sus organizaciones.

Aplicación de directivas

En la esquina superior derecha de GitHub, haz clic en la fotografía del perfil.
En función de tu entorno, haz clic en Your enterpriseo en Your enterprises y, a continuación, haz clic en la empresa que deseas ver.
En el lado izquierdo de la página, en la barra lateral de la cuenta de empresa, haz clic en Directivas.
En " Policies," haz clic en Acciones.
Después de configurar cada directiva, haga clic en Guardar.

Para obtener más información sobre cada sección de la página "Directivas", siga leyendo.

Directivas

En la sección "Directivas", puede controlar qué organizaciones de su empresa pueden utilizar GitHub Actions, con las siguientes opciones:

Habilitar GitHub Actions para todas las organizaciones
Habilitar GitHub Actions para organizaciones específicas
Inhabilitar GitHub Actions para todas las organizaciones

También puede limitar el uso de acciones públicas y flujos de trabajo reutilizables, con las siguientes opciones:

Permitir todas las acciones y flujos de trabajo reutilizables: se puede utilizar cualquier acción o flujo de trabajo reutilizable, sin importar quién lo haya creado o dónde se defina.
Permitir acciones empresariales y flujos de trabajo reutilizables: solo se pueden utilizar acciones y flujos de trabajo reutilizables definidos en un repositorio dentro de la empresa. Bloquea todo el acceso a las acciones creadas por GitHub, como la acción actions/checkout.
Permitir la empresa y seleccionar acciones no empresariales y flujos de trabajo reutilizables: se puede utilizar cualquier acción o flujo de trabajo reutilizable definido en un repositorio dentro de la empresa, además de cualquier acción o flujo de trabajo reutilizable que coincida con los criterios especificados.

Permitir la empresa y seleccionar acciones no empresariales y flujos de trabajo reutilizables

Si elige esta opción, se permiten acciones y flujos de trabajo reutilizables dentro de la empresa, y tendrá las siguientes opciones para permitir otras acciones y flujos de trabajo reutilizables:

Permitir acciones creadas por GitHub: permite todas las acciones creadas por GitHub, ubicadas en las organizaciones actions y github.
Permitir acciones de Marketplace de creadores verificados: permite todas las acciones de GitHub Marketplace creadas por creadores verificados, etiquetadas con .
Permitir las acciones especificadas y los flujos de trabajo reutilizables: permite las acciones y flujos de trabajo reutilizables que especifique. Puede especificar acciones individuales y flujos de trabajo reutilizables u organizaciones y repositorios completos.

Al especificar acciones y flujos de trabajo reutilizables, utilice la sintaxis siguiente:

Para restringir el acceso a etiquetas específicas o confirmar los SHA de una acción o un flujo de trabajo reutilizable, usa la misma sintaxis que se usa en el flujo de trabajo para seleccionar la acción o el flujo de trabajo reutilizable.
- Para una acción, la sintaxis es OWNER/REPOSITORY@TAG-OR-SHA. Por ejemplo, usa actions/javascript-action@v1.0.1 para seleccionar una etiqueta o actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f para seleccionar un SHA.
- Para un flujo de trabajo reutilizable, la sintaxis es OWNER/REPOSITORY/PATH/FILENAME@TAG-OR-SHA. Por ejemplo, octo-org/another-repo/.github/workflows/workflow.yml@v1.
Para especificar un patrón, utilice el carácter comodín, *.
- Para permitir todas las acciones y los flujos de trabajo reutilizables en las organizaciones que comienzan con space-org, utilice space-org*/*.
- Para permitir todas las acciones y los flujos de trabajo reutilizables en los repositorios que empiezan con octocat, utilice */octocat**@*.

Ejecutores

De manera predeterminada, cualquier usuario con acceso de administrador a un repositorio puede agregar un ejecutor autohospedado para el repositorio, y los ejecutores autohospedados conllevan riesgos:

No hay ninguna garantía de que los ejecutores autohospedados se vayan a hospedar en máquinas virtuales efímeras y limpias. Como resultado, el código que no es de confianza puede ponerlas en peligro en un flujo de trabajo.
Cualquier usuario que pueda bifurcar el repositorio y abrir una solicitud de cambios puede poner en peligro el entorno del ejecutor autohospedado, por lo que podría obtener acceso a secretos y a GITHUB_TOKEN, que puede tener acceso de escritura al repositorio.

En la sección "Ejecutores", puede mediar estos riesgos inhabilitando el uso de ejecutores autohospedados de nivel de repositorio.

Inhabilitar para todas las organizaciones: impide la creación de ejecutores en el nivel de repositorio.
Inhabilitar en todos los repositorios de usuarios administrados de Enterprise (EMU): impide la creación de ejecutores para repositorios que pertenecen a cuentas de usuario administradas.

Note

Cuando se deshabilita la creación de ejecutores autohospedados de nivel de repositorio, los flujos de trabajo pueden seguir teniendo acceso a los ejecutores autohospedados del nivel empresarial o de organización.

Retención de artefactos y registros

De manera predeterminada, los artefactos y archivos de registro que generan los flujos de trabajo se conservan durante 90 días. Puede cambiar el período de retención.

En el caso de los repositorios públicos, puede configurar un período entre 1 y 90 días.
Para repositorios privados e internos, puede configurar un período entre 1 y 400 días.

Los cambios solo se aplican a los nuevos artefactos y archivos de registro.

Bifurcar flujos de trabajo de solicitud de cambios de colaboradores externos

Cualquier usuario puede bifurcar un repositorio público y luego enviar una solicitud de cambios que proponga cambios en los flujos de trabajo del repositorio. Para no abusar, los flujos de trabajo no se ejecutarán de forma automática en las solicitudes de cambios creadas por algunos colaboradores.

Puede configurar qué solicitudes de cambios requieren aprobación antes de que se ejecuten.

Warning

Cuando se requieren aprobaciones solo para colaboradores por primera vez (las dos primeras configuraciones), un usuario que haya tenido cualquier confirmación o solicitud de cambios combinadas en el repositorio no requerirá aprobación. Un usuario malintencionado podría cumplir este requisito obteniendo un simple error tipográfico u otro cambio inocuo aceptado por un mantenedor, ya sea como parte de una solicitud de cambios que han creado o como parte de la solicitud de cambios de otro usuario.

Requerir aprobación para los colaboradores por primera vez que no están familiarizados con GitHub. Requiere aprobación para los usuarios que nunca han confirmado nada en el repositorio y tienen nuevas cuentas de GitHub.
Requerir aprobación para colaboradores por primera vez. Requiere aprobación para los usuarios que nunca han confirmado nada en el repositorio.
Requerir aprobación para todos los colaboradores externos. Requiere aprobación para todos los usuarios que no son miembros de la organización.

Note

Los flujos de trabajo de la rama base desencadenados por eventos pull_request_target siempre se ejecutarán, sin importar la configuración de aprobaciones.

Bifurcar flujos de trabajo de solicitud de cambios en repositorios privados

Puede controlar de qué manera los usuarios pueden ejecutar flujos de trabajo en eventos pull_request en repositorios privados e internos.

Ejecutar flujos de trabajo desde solicitudes de cambios de bifurcación. Los usuarios pueden ejecutar flujos de trabajo desde solicitudes de cambios de bifurcación. De manera predeterminada, los flujos de trabajo utilzarán un GITHUB_TOKEN con permiso de solo lectura, sin acceso a secretos.
Enviar tokens de escritura a flujos de trabajo de solicitudes de cambios. Los flujos de trabajo utilizarán un GITHUB_TOKEN con permiso de escritura.
Enviar secretos a flujos de trabajo desde solicitudes de cambios. Todos los secretos están disponibles para la solicitud de cambios.
Requerir aprobación para los flujos de trabajo de solicitud de cambios de bifurcación. Los flujos de trabajo en solicitudes de cambios de colaboradores sin permiso de escritura requerirán la aprobación de alguien con permiso de escritura antes de que se ejecuten.

Si se habilita una política para una empresa, esta puede inhabilitarse selectivamente en organizaciones o repositorios individuales. Si se inhabilita una política para una empresa, las organizaciones o repositorios individuales no pueden habilitarla.

Permisos de flujo de trabajo

En la sección "Permisos de flujo de trabajo", puede configurar los permisos predeterminados concedidos a GITHUB_TOKEN.

Permisos de lectura y escritura: de manera predeterminada, GITHUB_TOKEN tiene acceso de lectura y escritura para todos los ámbitos.
Leer el contenido del repositorio y los permisos de paquetes: de manera predeterminada, GITHUB_TOKEN solo tiene acceso de lectura para los ámbitos contents y packages. No se puede elegir la configuración más permisiva como valor predeterminado para organizaciones o repositorios individuales.

Cualquier usuario con acceso de escritura a un repositorio puede modificar los permisos que se han concedido a GITHUB_TOKEN para un flujo de trabajo específico si edita la clave permissions en el archivo de flujo de trabajo.

Permitir que Acciones de GitHub cree y apruebe solicitudes de cambios está deshabilitada de manera predeterminada. Si habilita esta configuración, GITHUB_TOKEN puede crear y aprobar solicitudes de cambios.