ATALAIAPregunta a un equipo quién puede desplegar a producción y la respuesta suele ser "solo a través del pipeline, con aprobación". Pregunta quién puede aprobar, quién puede cambiar el pipeline y quién puede llegar a las credenciales de producción sin él, y la respuesta se alarga.
Una aprobación de deploy es un control solo si no se puede saltar y el aprobador es independiente del cambio. Este checklist usa los entornos de GitHub como ejemplo, pero las preguntas valen para cualquier sistema de CI/CD.
El principio: separación de funciones
La separación de funciones significa que nadie puede llevar un cambio de la idea a producción por sí solo. En un pipeline se reduce a tres separaciones:
- EscribirUn ingeniero redacta el cambio y abre una pull request.
- RevisiónOtro ingeniero aprueba el código antes de que se mergee.
- ReleaseUn revisor obligatorio, distinto de quien lanzó la ejecución, aprueba el deploy a producción.
- DeployEl pipeline, no una persona, usa credenciales que solo existen dentro del entorno de producción.
Si una sola persona puede hacer dos de esos pasos sola, o saltarse uno, la aprobación es un trámite. La checklist sirve para encontrar dónde ocurre eso.
No es solo una preocupación de auditoría. La separación de funciones también limita lo que puede hacer una sola cuenta comprometida. Si un portátil víctima de phishing o un token personal filtrado puede hacer push, merge y release por sí solo, el atacante hereda todo el camino a producción de un solo golpe.
Entornos en GitHub Actions
Un entorno de GitHub asocia reglas de protección y secrets a los jobs que lo referencian. Un job que apunta a producción se queda en pausa hasta que se cumplen las reglas:
jobs:
deploy-prod:
runs-on: ubuntu-latest
environment:
name: production
url: https://app.example.com
permissions:
contents: read
id-token: write
steps:
- uses: actions/checkout@<full-length-commit-sha>
- name: Deploy
run: ./scripts/deploy.sh productionEn los ajustes del entorno configuras los revisores obligatorios, si quien lanzó la ejecución puede aprobarla, qué ramas o tags pueden desplegar y los secretos o variables que solo este entorno puede leer. Usar OIDC con tu proveedor cloud, con una trust policy ligada al claim del entorno production, significa que no hay ninguna clave de deploy de larga duración que pueda filtrarse.
El checklist
| # | Pregunta | Buena respuesta |
|---|---|---|
| 1 | ¿El entorno de producción tiene revisores obligatorios? | Sí, un equipo con nombre, no una persona concreta |
| 2 | ¿Puede aprobar la ejecución quien la lanzó? | No, «prevent self-review» está activado |
| 3 | ¿Qué branches o tags pueden desplegar a producción? | Solo la rama main protegida o tags de release firmados |
| 4 | ¿Los secretos de producción se guardan solo a nivel de entorno? | Sí, sin copias a nivel de repositorio ni de organización |
| 5 | ¿La política de confianza cloud exige el claim del entorno de producción? | Sí, el subject de OIDC está ligado al repo y al entorno |
| 6 | ¿Pueden los admins saltarse las reglas de entorno o la protección de ramas? | No, o el bypass se registra y se revisa |
| 7 | ¿Quién puede editar los ficheros de workflow en la rama main? | Los cambios en .github/workflows/ necesitan la revisión de un code owner |
| 8 | ¿Hay un inventario de activos? | Sin claves cloud personales ni roles de consola con permisos de deploy |
| 9 | ¿Puede una persona hacer merge y aprobar el deploy de su propio cambio? | No, el grupo de aprobadores excluye al autor del merge o las reglas lo imponen |
| 10 | ¿Queda registrada cada aprobación en algún sitio que puedas consultar? | Sí, el historial de deploys y el log de auditoría se conservan y se exportan |
Dónde suelen estar los huecos
- El break-glass que se convirtió en la puerta. Un bypass de administración de emergencia que se usa cada semana es el verdadero proceso de deploy.
- El workflow antiguo. Un job de deploy heredado, anterior a los environments, que aún guarda un secreto de repositorio.
- El equipo diminuto. Con dos ingenieros, separar funciones es difícil. Haz que la segunda persona apruebe y registra cada excepción en lugar de desactivar la regla.
- La edición del workflow. Si cualquiera puede cambiar el workflow en una branch con permiso para desplegar, puede quitar la línea
environment. Las restricciones de branch y la revisión de code owners en los ficheros de workflow lo cierran.
Hazlo en 30 minutos
- Lista cada workflow que pueda llegar a producción. Busca scripts de deploy, credenciales cloud y nombres de entorno.
- Para cada una, responde las diez preguntas con los ajustes del repositorio abiertos en pantalla.
- Marca como ticket con responsable cada «no» o «no estoy seguro».
- Corrige primero los bypasses: secretos sueltos, líneas
environmentque faltan, overrides de admin. - Repítelo cada vez que se añada un nuevo destino de deploy. Es la última puerta de la línea, así que vale la pena comprobarla dos veces.
Dónde encaja en la línea
En la torre (en desarrollo):