Checklist de seguridad para pipelines CI/CD con runners self‑hosted y gestión de secretos
Por Kevin Marcondes · Publicado el · 9 min de lectura
Este checklist de seguridad para pipelines CI/CD con runners self‑hosted y gestión de secretos se centra en controles prácticos: endurecimiento de hosts, aislamiento, políticas de mínimo privilegio, gestión de secretos, cadena de suministro y auditoría. Úsalo como referencia para reducir riesgos de fugas, secuestro de runners y manipulación de artefactos en entornos propios.
Amenazas comunes en CI/CD self‑hosted: entiende el terreno
Los runners self‑hosted ofrecen control y rendimiento, pero amplían la superficie de ataque. Amenazas típicas: filtrado de secretos en logs, jobs maliciosos, dependencias comprometidas, intrusión en el host del runner y secuestro de credenciales de despliegue. El primer paso es separar el entorno de build del de producción y aplicar aislamiento estricto, privilegios mínimos y rutinas de rotación de secretos.
Mapea quién dispara pipelines, a qué accede cada job, hacia dónde van los artefactos y qué redes están permitidas. Define límites claros: el runner no debe tener acceso directo a bases de datos o colas de producción sin controles adicionales y registros de auditoría.
Endurecimiento del host del runner y red: checklist esencial
Trata el host del runner como un activo sensible. Aplica hardening del sistema, actualizaciones automáticas e inventario de paquetes. Minimiza la superficie: deshabilita servicios innecesarios, activa firewall y limita puertos abiertos. Separa runners por sensibilidad (producción, homologación) en subredes distintas.
Reduce el egress. Permite solo los destinos necesarios: registries, mirrors, proveedores de dependencias, endpoints del CI y almacenes de secretos. Bloquea la entrada desde Internet. Prefiere NAT de salida, proxies autenticados y DNS interno con listas de permitidos.
Para un refuerzo base en servidores Linux, consulta este guía práctica de endurecimiento: checklist de seguridad para VPS Linux.
- Sistema actualizado y reinicios controlados
- Firewall restrictivo (deny by default) y logs de firewall
- Acceso SSH con claves, MFA en el bastión y sin root remoto
- Montajes temporales con noexec,nosuid,nodev cuando sea posible
- Monitorización y alertas del runner (CPU, disco, procesos)
- Backups e imágenes doradas solo como plantillas de runner
Runners efímeros, aislamiento y mínimo privilegio
Los runners efímeros reducen la persistencia de malware y los rastros de datos. Levanta un runner por job o por lotes pequeños y destrúyelo al terminar. Evita reutilizar directorios de trabajo. Ejecuta jobs como usuario sin privilegios, con controles de kernel (seccomp, AppArmor/SELinux) y cgroups para limitar recursos.
Si es posible, aísla cada job en contenedores o VMs ligeras. Desactiva docker‑in‑docker privilegiado; prefiere sockets limitados o runtimes con políticas. Los scopes y permisos de los tokens del CI deben ser mínimos y temporales.
Para arquitectura y automatización a escala, consulta: autoescalar runners self‑hosted en GitHub Actions.
- Runner por job o de corta duración
- Usuario sin privilegios; sin sudo en el job
- Políticas de seguridad de contenedor (seccomp, AppArmor)
- Límites de CPU/RAM/IO por job
- Tokens con scope mínimo y validez corta
- Limpieza segura del workspace al final del job
Gestión de secretos: políticas, flujo y controles de fuga
Centraliza secretos y reduce archivos .env persistentes. Usa secrets del CI, stores externos o emisión temporal vía OIDC para obtener credenciales bajo demanda. Aplica rotación periódica, versionado y trazabilidad de auditoría. En el pipeline, enmascara variables sensibles, bloquea echo y sanitiza logs y artefactos.
Restringe secretos por entorno y branch. Evita pasar secretos a jobs que no los necesitan. Prefiere montar secretos en memoria (tmpfs) y eliminarlos tras su uso. Escanea repositorios y artefactos en busca de secretos comprometidos.
En el mundo Docker, evita ARG/ENV con secretos en Dockerfiles. Inyéctalos solo en tiempo de build con alcance restringido y sin dejar rastro en las capas de la imagen.
| Opción | Cómo funciona | Cuándo usar | Riesgos/precauciones |
|---|---|---|---|
| .env en el servidor del runner | Archivo local leído por el job | Pruebas de concepto y entornos temporales | Alta probabilidad de filtrado y drift; evitar en producción |
| Secrets nativos del CI | Almacenados e inyectados por el proveedor del CI | Equipos pequeños/medianos; menor complejidad | Control de alcance por branch/entorno; cuidado con logs |
| Secrets Manager/Vault externo | Cofre central con políticas y rotación | Múltiples sistemas y auditoría fuerte | Complejidad operativa, latencia y costes |
| KMS + OIDC (credenciales temporales) | Emisión bajo demanda y corta duración | Cloud o híbrido con identidad federada | Requiere configuración fina de IAM y confianza en el emisor |
Cadena de suministro: dependencias, builds y firma
Tu imagen base y tus dependencias son parte del perímetro. Fija versiones, usa checksums y bloquea actualizaciones no revisadas. Genera SBOM en cada build y almacénalo junto al artefacto. Escanea dependencias e imágenes en busca de CVEs antes de proceder al deploy.
Firma imágenes y artefactos y publica atestaciones de procedencia. Mantén caches, mirrors y registries privados controlados. Trata el cache como no confiable: valida los outputs. Para un registry privado y autenticado, consulta: Registry Docker privado con mirror en VPS.
Para acelerar builds sin relajar controles, revisa: BuildKit y cache remoto en CI.
- Fijar versiones y verificar integridad de descargas
- Generar SBOM y almacenar con el artefacto
- Firmar imágenes/artefactos y validar en el despliegue
- Bloquear egress a repositorios no aprobados
- Escanear CVEs antes y fallar el build si hay alto riesgo
Protección de artefactos, logs y canales de despliegue
Define políticas de retención y acceso a artefactos. Almacena en repositorios con trazabilidad, inmutabilidad y versionado. Separa roles: quien hace merge no debería poder alterar artefactos firmados. En deploy, valida firmas y atestaciones antes de promover entre etapas.
Reduce la sensibilidad de los logs: enmascara variables y elimina trazas de stack excesivas en jobs sensibles. Limpia directorios temporales al final. Usa cuentas de servicio dedicadas para CD, con permisos mínimos y ventanas de tiempo limitadas.
Para servicios internos expuestos al pipeline, emplea autenticación mutua entre servicios. Guía práctica: mTLS en Docker Compose.
- Retención mínima necesaria, con WORM cuando aplique
- Firma verificada como gate de promoción
- Cuentas de servicio separadas por entorno
- Enmascaramiento de logs y limpieza de workspaces
- Aprobaciones manuales para cambios de alto riesgo
Auditoría continua, pruebas y respuesta a incidentes
Registra quién disparó el pipeline, hash del commit, ID del runner, versiones de herramientas, digest de artefactos y decisiones de política. Centraliza logs con correlación entre etapas. Prueba periódicamente la recuperación de secretos y la rotación de claves.
Prepara runbooks de incidente para: filtrado de secretos, compromiso de runner, dependencia maliciosa y fallo de firma. Ten un camino de break‑glass controlado, con expiración corta y auditoría estricta. Revisa trimestralmente permisos e inventario de secretos.
- Recolectar y retener logs de auditoría con integridad
- Pruebas de rotación de secretos y revocación de credenciales
- Runbooks con responsables y SLAs internos
- Revisiones periódicas de IAM y escaneo de repositorios
Checklist resumido para aplicar hoy
Usa esta lista como punto de partida. Adáptala a tu contexto y riesgos. Prioriza ítems de mayor impacto y menor esfuerzo, y evoluciona en ciclos cortos con métricas de reducción de exposición e incidentes evitados.
- Runners efímeros, sin sudo, con políticas de kernel
- Host endurecido, firewall restrictivo y egress mínimo
- Secretos centralizados, enmascarados y rotados
- OIDC para credenciales temporales cuando sea posible
- Fijar versiones, generar SBOM y firmar artefactos
- Escaneos de CVEs que bloqueen el build en alto riesgo
- Artefactos en storage versionado y verificación de firma en deploy
- Cuentas de servicio con mínimo privilegio por entorno
- Logs enmascarados y trazabilidad de punta a punta
- Runbooks, drills y revisión periódica de permisos
Preguntas frecuentes
¿Qué cambia en la seguridad al usar runners self‑hosted?
Pasas a proteger también el host y la red del runner. Es necesario hardening del sistema, aislamiento por job, control de egress, rotación de secretos y auditoría completa. Sin estos controles, el runner puede filtrar secretos, ser secuestrado para despliegues maliciosos o exponer tu infraestructura interna.
¿Los runners efímeros realmente reducen el riesgo?
Sí. Descartar el runner tras cada job elimina la persistencia de malware, reduce la posibilidad de filtrado por reutilización de workspace y fuerza una configuración conocida por template. Combinados con usuario sin privilegios y tokens cortos, disminuyen la ventana de ataque y el impacto de compromisos.
¿Cómo evitar el filtrado de secretos en los logs del pipeline?
Activa el enmascaramiento de variables, prohíbe comandos que impriman valores sensibles y revisa scripts para no mostrar secretos. Inyecta secretos solo en el ámbito necesario, monta en memoria cuando sea posible y realiza escaneos automáticos en repositorios y artefactos para detectar exposiciones accidentales.
¿OIDC puede sustituir archivos .env en CI/CD?
En muchos escenarios, sí. OIDC permite emitir credenciales temporales bajo demanda, evitando claves estáticas en .env. Con políticas de IAM bien definidas reduces filtrados y facilitas la rotación. Aun así, algunos sistemas legados pueden requerir una integración gradual o un cofre central paralelo.
¿Con qué frecuencia rotar los secretos?
Depende del riesgo y del sistema. Como regla, rota secretos sensibles en ventanas cortas y siempre tras incidentes o cambios de personal. Automatiza la rotación cuando sea posible y mantiene registro de versiones para rollback seguro. Usa credenciales temporales para reducir la necesidad de claves de larga duración.
¿Dónde almacenar con seguridad los artefactos generados por el CI?
Usa repositorios de artefactos con versionado y controles de acceso. Prefiere storages con inmutabilidad (WORM) y vincula cada artefacto a su hash de commit y SBOM. Exige validación de firma antes de promover entre entornos, manteniendo trazabilidad de auditoría y retención adecuada.
¿Quieres convertir este checklist en mejoras reales?
Hablemos sobre cómo adaptar estos controles a tu pipeline CI/CD, priorizar riesgos y establecer auditoría continua con el mínimo fricción.
Hablar sobre tu pipeline CI/CDVer también
- Guía: checklist de pre‑deploy y plan de rollback rápido para aplicaciones PHP en producción
- Guía: centralización de logs con Fluentd y Elasticsearch para aplicaciones PHP en VPS
- Guía: organizar migraciones y rollbacks en PostgreSQL para equipos pequeños
- Guía práctica: cómo autoescalar runners self‑hosted en GitHub Actions para pipelines CI de proyectos PHP