¿Cómo gestionas los secretos en un pipeline de construcción y despliegue?

Mantén las credenciales de larga duración completamente fuera del pipeline. Usa federación de identidad de cargas de trabajo para que el job de CI intercambie un token OIDC de corta duración por un rol acotado, y saca los secretos de aplicación en tiempo de ejecución desde un gestor de secretos en vez de inyectarlos en el build. Acota cada secreto a un entorno y un consumidor, rota automáticamente, audita los accesos y enmascáralos en los logs. Nunca hornees secretos dentro de imágenes ni los subas al repositorio, ni siquiera cifrados, sin gestión de claves.

Mi posición de partida es que el pipeline no debería guardar ninguna credencial de nube de larga duración. El proveedor de CI emite un token de identidad firmado para el job, la nube confía en ese emisor y el job lo intercambia por un rol que dura minutos y está acotado a un entorno. Eso elimina toda la categoría de una clave estática filtrada viviendo tres años en la configuración de un repositorio. Los secretos de aplicación son otro asunto y su sitio es el tiempo de ejecución, sacados de un gestor de secretos por la propia carga de trabajo con su identidad, así que una contraseña de base de datos no pasa nunca por el build. Si tengo que guardar secretos cifrados en git, por ejemplo en un repositorio de GitOps, van cifrados contra un servicio de gestión de claves, así que lo que controlo de verdad es el derecho a descifrar y no el fichero. Todo va acotado de forma estrecha, rotado con una periodicidad y con los accesos registrados. Y planifico las filtraciones: revocar primero, rotar y luego calcular el radio de impacto desde el rastro de auditoría, porque intentar demostrar que nadie la usó antes de revocar es el orden equivocado.