Aplicación de directivas para GitHub Actions en la empresa

Puede aplicar directivas para administrar la forma en que GitHub Actions puede utilizarse dentro de su empresa.

¿Quién puede utilizar esta característica?

Enterprise owners

En este artículo

¿Qué son las directivas para las 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.

Nota:

GitHub Actions debe estar habilitado para los repositorios de una organización para que la configuración predeterminada de CodeQL code scanning y los flujos de trabajo de GitHub Code Quality se ejecuten. Sin embargo, la configuración predeterminada de CodeQL para code scanning no se ve afectada por otras directivas GitHub Actions (como restringir el acceso a acciones públicas o flujos de trabajo reutilizables).

Aplicación de directivas

  1. Vaya a su empresa. Por ejemplo, desde la página Empresas en GitHub.com.
  2. En la parte superior de la página, haz clic en Policies.
  3. En " Policies", haz clic en Actions.
  4. 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
  • Deshabilitar GitHub Actions para todas las organizaciones

Nota:

Si deshabilita GitHub Actions, o no habilita la característica para una o varias organizaciones, esto impide que las organizaciones afectadas usen code scanning y análisis de GitHub Code Quality.

Control del acceso a acciones públicas y flujos de trabajo reutilizables

Las empresas suelen querer limitar el acceso solo a un grupo bien probado de acciones públicas y flujos de trabajo reutilizables como parte de su gobernanza de la cadena de suministro. Las directivas disponibles en GitHub permiten controlar el acceso sin bloquear los flujos de trabajo dinámicos usados por code scanning y GitHub Code Quality.

Puede aplicar controles estrictos sin definir excepciones ni configuración adicional para code scanning y GitHub Code Quality, 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`](https://github.com/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.
  •         **Requerir que las acciones se anclen a un SHA de confirmación de longitud completa**: todas las acciones deben anclarse a un SHA de confirmación de longitud completa para usarse. Esto incluye las acciones de tu empresa y las acciones creadas por GitHub. La etiqueta puede hacer referencia a flujos de trabajo reutilizables. Para más información, consulta [AUTOTITLE](/actions/reference/security/secure-use#using-third-party-actions).

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`](https://github.com/actions) y [`github`](https://github.com/github).

  •         **Permitir acciones de Marketplace de creadores verificados:** permite todas las acciones de GitHub Marketplace creadas por creadores verificados, etiquetadas con <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-verified" aria-label="The verified badge" role="img"><path d="m9.585.52.929.68c.153.112.331.186.518.215l1.138.175a2.678 2.678 0 0 1 2.24 2.24l.174 1.139c.029.187.103.365.215.518l.68.928a2.677 2.677 0 0 1 0 3.17l-.68.928a1.174 1.174 0 0 0-.215.518l-.175 1.138a2.678 2.678 0 0 1-2.241 2.241l-1.138.175a1.17 1.17 0 0 0-.518.215l-.928.68a2.677 2.677 0 0 1-3.17 0l-.928-.68a1.174 1.174 0 0 0-.518-.215L3.83 14.41a2.678 2.678 0 0 1-2.24-2.24l-.175-1.138a1.17 1.17 0 0 0-.215-.518l-.68-.928a2.677 2.677 0 0 1 0-3.17l.68-.928c.112-.153.186-.331.215-.518l.175-1.14a2.678 2.678 0 0 1 2.24-2.24l1.139-.175c.187-.029.365-.103.518-.215l.928-.68a2.677 2.677 0 0 1 3.17 0ZM7.303 1.728l-.927.68a2.67 2.67 0 0 1-1.18.489l-1.137.174a1.179 1.179 0 0 0-.987.987l-.174 1.136a2.677 2.677 0 0 1-.489 1.18l-.68.928a1.18 1.18 0 0 0 0 1.394l.68.927c.256.348.424.753.489 1.18l.174 1.137c.078.509.478.909.987.987l1.136.174a2.67 2.67 0 0 1 1.18.489l.928.68c.414.305.979.305 1.394 0l.927-.68a2.67 2.67 0 0 1 1.18-.489l1.137-.174a1.18 1.18 0 0 0 .987-.987l.174-1.136a2.67 2.67 0 0 1 .489-1.18l.68-.928a1.176 1.176 0 0 0 0-1.394l-.68-.927a2.686 2.686 0 0 1-.489-1.18l-.174-1.137a1.179 1.179 0 0 0-.987-.987l-1.136-.174a2.677 2.677 0 0 1-1.18-.489l-.928-.68a1.176 1.176 0 0 0-1.394 0ZM11.28 6.78l-3.75 3.75a.75.75 0 0 1-1.06 0L4.72 8.78a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L7 8.94l3.22-3.22a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042Z"></path></svg>..

  •         **Permitir  o bloquear acciones especificadas y 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, use space-org*/*.
    • Para permitir todas las acciones y los flujos de trabajo reutilizables en los repositorios que empiezan con octocat, utilice */octocat**@*.
  • Para especificar varios patrones, usa , para separar los patrones.
    • Para permitir todas las acciones y los flujos de trabajo reutilizables de las organizaciones octocat y octokit, usa octocat/*, octokit/*.
  • Para bloquear patrones específicos, usa el prefijo !.
    • Para permitir todas las acciones y los flujos de trabajo reutilizables de la organización space-org, pero bloquear una acción concreta como space-org/action, usa space-org/*, !space-org/action@*.
    • De manera predeterminada, solo se permitirán las acciones y los flujos de trabajo reutilizables especificados en la lista. Para permitir todas las acciones y los flujos de trabajo reutilizables al tiempo que se bloquean acciones específicas, usa *, !space-org/action@*.

Las directivas nunca restringen el acceso a las acciones locales en el sistema de archivos del ejecutor (donde la ruta de uses: comienza por ./).

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 incorporación 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 evitar estos riesgos deshabilitando el uso de ejecutores autohospedados de nivel de repositorio.

  •         **Deshabilitar para todas las organizaciones**: impide la creación de ejecutores en el nivel de repositorio.

  •         **Deshabilitar 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.

Nota:

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.

Imágenes personalizadas

En la sección "Imágenes personalizadas", puede controlar qué organizaciones de su empresa pueden crear y administrar imágenes personalizadas con la siguiente directiva de acceso:

  •         **Habilitar para todas las organizaciones**: todas las organizaciones, incluidas las creadas en el futuro, pueden usar o crear imágenes personalizadas.

  •         **Habilitar para organizaciones específicas**: solo las organizaciones seleccionadas pueden usar o crear imágenes personalizadas.

  •         **Deshabilitar para todas las organizaciones**: ninguna organización puede usar ni crear imágenes personalizadas.

Directivas de retención de imágenes personalizadas

Puede definir cuánto tiempo se conservan las versiones de imágenes personalizadas y cuándo se vuelven inactivas.

  •         **Versiones máximas por imagen**: limita el número de versiones de cada imagen que se conservan. Cuando se supera este límite, las versiones de imagen sin usar más antiguas se eliminan automáticamente.
    * Valor predeterminado: 20 versiones * Intervalo configurable: versiones de 1 a 100
  •         **Retención de versiones sin usar**: elimina las versiones de imagen que no se han usado durante un número especificado de días. Las versiones de imagen asignadas a un grupo de ejecutores, pero que no se usan activamente, también se consideran no utilizadas.
    * Valor predeterminado: 30 días. * Intervalo configurable: de 1 a 90 días
  •         **Antigüedad máxima de la versión**: deshabilita las versiones de imagen que se crearon antes del número de días especificado. Los ejecutores no pueden utilizar versiones de imagen deshabilitadas hasta que se aumente el límite de la directiva.
    * Valor predeterminado: 60 días * Intervalo configurable: de 7 a 90 días

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.

Configuración de la caché

Puede configurar los límites máximos de retención y tamaño de caché que se aplicarán en toda la empresa. Si aumenta el límite de expulsión de tamaño de caché más allá de los 10 GB incluidos en el plan, se le cobrará por cualquier almacenamiento adicional de entradas almacenadas en caché.

De manera predeterminada:

  • Las memorias caché se conservan durante 7 días antes de la eliminación automática.
  • El límite total de almacenamiento en caché es de 10 GB por repositorio.

Puede personalizar esta configuración para establecer límites máximos para la retención de caché y el tamaño de almacenamiento de caché en toda la empresa:

  •         **Retención de caché**: configure hasta 90 días para repositorios públicos o 365 días para repositorios privados e internos.

  •         **Límite de expulsión de tamaño de caché**: configure hasta 10 000 GB por repositorio.

Las opciones que configure en el nivel empresarial actúan como límites máximos. Los propietarios de la organización pueden optar por configurar límites para su organización, pero no pueden superar los límites establecidos en el nivel empresarial. Los administradores del repositorio pueden optar por configurar límites para sus repositorios, pero no pueden superar los límites establecidos en el nivel de organización.

Para obtener más información sobre la expulsión de caché, consulte Referencia de almacenamiento en caché de dependencias.

Bifurcación de los flujos de trabajo de solicitud de incorporación de cambios de colaboradores externos

Cualquier usuario puede bifurcar un repositorio público y luego enviar una solicitud de incorporación 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 incorporación de cambios creadas por algunos colaboradores.

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

Advertencia

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 incorporación 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 inofensivo aceptado por un mantenedor, ya sea como parte de una solicitud de incorporación de cambios que han creado o como parte de la solicitud de incorporación 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.

Nota:

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.

Bifurcación de flujos de trabajo de solicitud de incorporación 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 incorporación de cambios de bifurcación**. Los usuarios pueden ejecutar flujos de trabajo desde solicitudes de de incorporación cambios de bifurcación. De manera predeterminada, los flujos de trabajo utilizarán un `GITHUB_TOKEN` con permiso de solo lectura, sin acceso a secretos.

  •         **Enviar tokens de escritura a flujos de trabajo de solicitudes de incorporación de cambios**. Los flujos de trabajo utilizarán un `GITHUB_TOKEN` con permiso de escritura.

  •         **Enviar secretos a flujos de trabajo desde solicitudes de incorporación de cambios**. Todos los secretos están disponibles para la solicitud de incorporación de cambios.

  •         **Requerir aprobación para los flujos de trabajo de solicitud de incorporación de cambios de bifurcación**. Los flujos de trabajo en solicitudes de incorporación 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:** los permisos predeterminados de `GITHUB_TOKEN` dependen de cuándo se creó la empresa o la organización:

    * El 2 de febrero de 2023 o después: el valor predeterminado es acceso de solo lectura para todos los ámbitos. * Antes del 2 de febrero de 2023: el valor predeterminado es 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 GitHub Actions pueda crear y aprobar pull requests** está deshabilitado por defecto. Si habilita esta configuración, `GITHUB_TOKEN` puede crear y aprobar solicitudes de cambios.