Coolify anuncia en sus notas de la versión 4.6.0 una serie de cambios centrados en endurecer la seguridad de sus pipelines de GitHub Actions y en limitar las capacidades de eliminación a través de la API y del servidor MCP. Las novedades buscan reducir el riesgo de ejecución de código no-verificado y prevenir borrados accidentales o maliciosos desde tokens con permisos reducidos.
Qué cambia en los permisos de borrado (delete)
La versión introduce cambios incompatibles (breaking changes) en la forma en que se permiten las operaciones de eliminación. A partir de ahora, para que una petición de borrado (delete) —ya sea de recursos, variables de entorno, almacenamiento, backups, tareas programadas o etiquetas— pueda completarse, debe cumplirse una de estas condiciones:
- que el token usado tenga la nueva capacidad explícita de delete, o
- que la petición sea realizada por el root (administrador).
En consecuencia, un token de API que solo tenga permisos de escritura (write alone) ya no podrá eliminar recursos ni realizar operaciones de detach sobre etiquetas. Esto obliga a revisar los tokens automatizados y scripts que hasta ahora usaban solo permisos de escritura para realizar limpiezas o cambios destructivos.
Hardening de los flujos CI en GitHub Actions
Coolify describe varias medidas para asegurar que las ejecuciones en GitHub Actions sean reproducibles y no dependan de artefactos externos modificables:
- Requerir que cada acción usada en los workflows esté fijada a un SHA de commit de longitud completa (full-length commit SHA). Esto se complementa con una política de Actions en GitHub que obliga a usar esta fijación.
- Bloquear cada acción y las acciones que ésta invoque en un archivo .github/workflows/actions.lock, incluyendo también los identificadores (IDs) del propietario y del repositorio de la acción. El lockfile añade comprobaciones que un SHA por sí solo no realiza.
- Exigir que cada workflow utilice dicho archivo de lock mediante una política de Actions en GitHub.
- Evitar el uso de caches compartidos en las ejecuciones: no se restaurarán caches de GitHub Actions, caches de capas de Docker ni binarios de herramientas en caché, de modo que ninguna ejecución pueda reutilizar artefactos escritos por otra.
- Asegurar que a cada job se le otorguen únicamente los permisos mínimos necesarios (principio de menor privilegio) y documentar la razón para cada permiso de escritura concedido.
Separación de secretos y entornos de ejecución
La nota señala medidas para aislar credenciales sensibles en entornos de ejecución controlados por rama:
- Las credenciales de Docker Hub y el token de CDN se mantienen en el entorno de release, accesible únicamente a las ramas que realizan releases.
- Los tokens que autorizan la eliminación de imágenes quedan en el entorno de cleanup, accesible únicamente desde la rama main.
- Se ocultan los valores de variables de entorno bloqueadas en las listas de recursos devueltas por las rutas GET /api/v1/resources y GET /api/v1/projects/{uuid}/{environment}, evitando exponer secretos en respuestas API donde antes podían aparecer.
Medidas adicionales de integridad y protección de ramas
Entre otras acciones de seguridad, Coolify documenta las siguientes protecciones:
- Rechazo de actualizar, forzar push (force-push) o eliminar la etiqueta (git tag) de un release mediante una regla de protección de tags en GitHub.
- Prohibición de eliminar o forzar push sobre las ramas main, next, release y maintenance mediante reglas de protección de ramas en GitHub.
- Corrección de todos los hallazgos marcados por la herramienta jactionlint en modo pedantic.
Qué deben hacer administradores y responsables de proyectos
Las notas indican acciones prácticas que conviene aplicar:
- Revisar y actualizar tokens de API y roles: conceder la nueva capacidad de delete solo a los tokens o cuentas que realmente la necesiten, y evitar usar tokens de solo escritura para tareas que borren recursos.
- Adoptar el lockfile .github/workflows/actions.lock y fijar acciones a SHAs completos en los workflows, además de habilitar las políticas de Actions en los repositorios para exigir dichas prácticas.
- Revisar la configuración de entornos y secretos: asegurar que credenciales sensibles estén en los entornos de rama adecuados (release, cleanup) y que las protecciones de ramas y tags estén activas en GitHub.
- Adaptar pipelines para no depender de caches compartidos y validar que cada job pide solo los permisos estrictamente necesarios.
Las medidas descritas en Coolify 4.6.0 son coherentes con buenas prácticas de seguridad para CI/CD y control de acceso en plataformas de despliegue automático; sin embargo, requieren cambios operativos en tokens, workflows y políticas de repositorio que los equipos deben planificar antes de actualizar o desplegar esta versión.
Lee también:
- Audacity 4.0.2 restaura el autosave en grabación y corrige corrupción de proyectos
- KDE Linux activa NTSYNC por defecto para mejorar juegos con Wine y Proton
Fuente: Release notes from coolify
