📋 Contenido
Si tu pipeline despliega en AWS con una clave guardada en los secretos del repo, tienes una bomba de relojería: esa clave no caduca, no se rota, y el día que se filtre en un log, es acceso total. La forma moderna se llama OIDC: el pipeline asume un rol temporal y no guarda ninguna clave. Te lo enseño en
El problema de la clave de larga duración: vive para siempre, se copia a más sitios de los que recuerdas, y aparece donde no debe: un log verboso, un fork del repo, el portátil de alguien que ya no está. Y las claves del CI suelen tener permisos de despliegue: de las gordas.
- La clave larga: no caduca
- Se copia
- Acaba en un log o un fork. Y la del CI suele poder DESPLEGAR.
¿Cómo funciona OIDC?
OIDC funciona así: GitHub Actions le presenta a AWS un token firmado que dice soy el repo tal, rama main, job de deploy. AWS lo verifica y le presta un rol solo durante ese job. Sin clave guardada, no hay clave que filtrar; y el rol se restringe a ese repo y esa rama exactos.
GitHub presenta un token firmado → AWS lo verifica → presta un ROL solo durante ese job, atado a repo+rama.
.github/workflows/deploy.yml
Y el cambio en tu workflow es este: pides permiso de token de identidad, y en vez de pegar claves, usas la action oficial de credenciales apuntando al rol. Fíjate en lo que no hay: ni access key, ni secret. Cero secretos guardados.
permissions: id-token: write
- uses: aws-actions/configure-aws-credentials@v4
with: role-to-assume: arn:aws:iam::…:role/deploy-web
Cero claves guardadas en el repo
Las reglas del pipeline
Para el resto de secretos del pipeline, las reglas: nunca en el YAML ni en el código; los de runtime viven en Secrets Manager o Parameter Store y la app los lee con su rol; máscara activada en los logs; y un escáner de secretos, gitleaks por ejemplo, corriendo en cada push.
- Nada de secretos en YAML ni código
- Runtime → Secrets Manager / Parameter Store
- Máscara de secretos en los logs del CI
- Escáner (gitleaks) en cada push
Tu pipeline ya no guarda secretos. Siguiente agujero clásico: el bucket de S3 que quedó público. Cuatro capas para un S3 sin fugas:
Preguntas frecuentes
¿Qué puede salir mal? Si ya hay claves sueltas
¿Y si ya tienes claves repartidas por ahí? No te fustigues: prioriza. Rota hoy la del CI, que es la más gorda, activa el escaneo de secretos que GitHub ya trae, y migra pipeline a pipeline a OIDC. En una semana de ratos libres queda hecho.
Prioriza: rota la del CI HOY → activa el secret scanning de GitHub → migra a OIDC pipeline a pipeline.
¿Qué detalle sorprende a casi todos?
Para recordar este artículo: la mejor clave es la que no existe. Un rol prestado durante tres minutos no puede filtrarse mañana.
La mejor clave es la que NO existe: un rol de 3 minutos no se filtra mañana.
¿Por dónde empiezo?
Para el resto de secretos del pipeline, las reglas: nunca en el YAML ni en el código; los de runtime viven en Secrets Manager o Parameter Store y la app los lee con su rol; máscara activada en los logs; y un escáner de secretos, gitleaks por ejemplo, corriendo en cada push.