Dónde guardar la configuración y los secretos

Trata de forma distinta los valores no sensibles, como las URL de servicios y las opciones de funciones, y las credenciales, como contraseñas, claves de API y claves privadas. No incluyas credenciales reales en el código ni confirmes archivos que las contengan en un repositorio compartido. Comprueba primero qué mecanismos de configuración admite la aplicación.

Si las herramientas lo permiten, guarda los valores locales de cada persona en un archivo .env y comparte un .env.example que contenga solo nombres de variables y valores de ejemplo. Añade el .env real a .gitignore y comprueba que Git no lo esté siguiendo ya. La exclusión de Git no es un almacén seguro ni borra valores del historial existente.

En sistemas de CI como GitHub Actions, registra las credenciales mediante la función de secretos del proveedor, no dentro de los archivos del flujo de trabajo. Restringe el acceso a los repositorios, entornos y tareas que las necesiten, concede a los tokens solo los permisos imprescindibles y evita imprimir valores. El enmascaramiento de registros no garantiza que se oculten todos los valores transformados o resultados de comandos.

En producción, prioriza el almacén de secretos del proveedor de alojamiento o de la nube y limita qué despliegues y servicios pueden leer cada valor. Docker Compose puede montar secretos como archivos para los servicios autorizados expresamente; las funciones y limitaciones dependen de la plataforma, así que consulta la documentación del entorno real. Si es posible, considera credenciales de corta duración, como OIDC, en lugar de claves duraderas.

Si un secreto pudo aparecer en un commit, un registro de CI o un chat, no basta con borrar la copia visible. Revoca o renueva primero la clave o el token afectado y revisa los registros de acceso y su posible uso. Después, aborda el historial del repositorio y los registros según corresponda, y refuerza los permisos para evitar que vuelva a ocurrir.