Aplicación de directivas para Acciones de GitHub en la empresa

¿Qué son las directivas para GitHub Actions?

Las directivas empresariales controlan las opciones que están disponibles para los miembros de la empresa cuando usan 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 sus organizaciones.

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, haga clic en Directivas.
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 usar 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

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 usar cualquier acción o flujo de trabajo reutilizable, independientemente de quién lo haya creado o dónde se defina.
• Permitir acciones empresariales y flujos de trabajo reutilizables: solo se pueden usar 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 actions/checkout acción.
• Permitir la empresa y seleccionar acciones no empresariales y flujos de trabajo reutilizables: se puede usar 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 acciones de la empresa y las acciones creadas por GitHub. Las etiquetas todavía pueden hacer referencia a los flujos de trabajo reutilizables. Para obtener más información, vea Referencia de uso seguro.

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 por creadores comprobados: Permite todas las GitHub Marketplace acciones creadas por creadores comprobados, etiquetadas con .
• Permitir o bloquear acciones especificadas y flujos de trabajo reutilizables: permite acciones y flujos de trabajo reutilizables que especifique. Puede especificar acciones individuales y flujos de trabajo reutilizables o organizaciones y repositorios completos.

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

• Para restringir el acceso a etiquetas específicas o a SHA de commits de una acción o de un flujo de trabajo reutilizable, utilice 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 flujos de trabajo reutilizables de las organizaciones que comienzan por space-org, use space-org*/*.
  • Para permitir todas las acciones y flujos de trabajo reutilizables en repositorios que comienzan con octocat, use */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 flujos de trabajo reutilizables de la space-org organización, pero bloquee una acción específica como space-org/action, use space-org/*, !space-org/action@*.
  • De forma predeterminada, solo se permitirán acciones y flujos de trabajo reutilizables especificados en la lista. Para permitir todas las acciones y flujos de trabajo reutilizables al mismo tiempo que bloquean acciones específicas, use *, !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 por la empresa (EMU): Impide la creación de runners para repositorios que pertenecen a cuentas de usuario administradas.

Deshabilitación de ejecutores hospedados estándar

Puede deshabilitar los ejecutores estándar alojados en GitHub a nivel de empresa. Esta configuración requiere que los flujos de trabajo se dirijan a los ejecutores mediante grupos de ejecutores y contribuye a aplicar controles de acceso y una gobernanza coherentes.

Para obtener información sobre los límites de simultaneidad de los trabajos de los runners hospedados en GitHub, consulte Límites de acciones.

1. Vaya a su empresa. Por ejemplo, desde la página Empresas en GitHub.com.
2. En la parte superior de la página, haga clic en Directivas.
3. En " Policies", haz clic en Actions.
4. Desplácese hasta la sección "Ejecutores hospedados estándar" y haga clic en Deshabilitar para todas las organizaciones.
5. Haz clic en Guardar.

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.

• Exigir aprobación para los colaboradores primerizos que son nuevos en GitHub Requiere aprobación para los usuarios que nunca se han confirmado en el repositorio y tienen nuevas GitHub cuentas.
• 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.

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 Acciones de GitHub pueda crear y aprobar pull requests está deshabilitado por defecto. Si habilita esta configuración, GITHUB_TOKEN puede crear y aprobar solicitudes de cambios.