Ejecutores propios en GitHub y en GitLab

En un repositorio público cualquiera puede bifurcarlo y abrir una propuesta cuyo flujo corre en el ejecutor. La documentación de seguridad de GitHub dice que los ejecutores propios casi nunca deben usarse con repositorios públicos: el código de un desconocido correría en una máquina de la empresa y, si es persistente, podría dejar algo para los trabajos siguientes.

En GitLab, el equivalente es la opción de ejecutor protegido, que lo limita a ramas o etiquetas protegidas, y el cuidado con el ejecutor de shell, que no aísla el trabajo del anfitrión.

Cruza las dos tablas: cada trabajo dice en qué ejecutor corre y de qué repositorio es. Busca el trabajo de un repositorio público que corre en un ejecutor propio que no se limpia entre trabajos.

Un ejecutor de GitLab que despliega a producción y atiende pipelines de cualquier rama deja que quien cree una rama con permiso de escritura lance código en una máquina de la red de producción. Existen dos ejecutores de despliegue casi iguales: se diferencian en una sola columna.

La exposición se mide en trabajos: cada trabajo que corre en un ejecutor que se reutiliza y está dentro de una red interna (incluida la de producción) puede heredar lo que dejó el anterior y ve desde ahí lo que ve la red. Cuenta los trabajos de la tabla en esa situación, de las dos plataformas.

Sin ejecutores propios no hay problema, pero Mirto Pagos los necesita para desplegar dentro de su red. La documentación de ambos CI orienta hacia ejecutores que no conservan estado entre trabajos y hacia repartirlos por nivel de confianza: lo público, fuera de la red interna.