Agregue .env a .gitignore
Reduce el riesgo de incorporar credenciales al repositorio por error.
Riesgos asociados al manejo de contraseñas y claves en proyectos Docker, limitaciones de los archivos .env, y prácticas iniciales para mitigar la exposición. Recorra cada sección para ver los detalles.
Concepto 1 de 5
Los archivos .env contienen credenciales en texto plano que pueden quedar expuestas de forma permanente en el historial de versiones.
# .env con credenciales en texto planoPOSTGRES_USER=adminPOSTGRES_PASSWORD=SuperSecretPassword123!API_KEY=sk-live-a1b2c3d4e5f6g7h8i9j0JWT_SECRET=my-jwt-secret-key-2024Si este archivo se incorpora al repositorio por error, las credenciales quedan registradas en el historial de Git. Incluso si se elimina el archivo posteriormente, los valores permanecen accesibles en commits anteriores.
Recorra las etapas para ver qué ocurre con la contraseña en el historial.
git log --oneline
a1f3c09 Estructura inicial: compose.yml y DockerfileVersión actual
compose.yml · Dockerfile
Credencial
No expuesta
$ git show 7b2e4d1:.env | grep PASSWORD fatal: invalid object name '7b2e4d1'.
El repositorio solo contiene compose.yml y el Dockerfile. Ninguna credencial está versionada.
Concepto 2 de 5
Aceptable en desarrollo, pero con limitaciones importantes que conviene conocer.
env o mediante docker inspect..env compartido entre integrantes puede circular sin control y aumentar el riesgo de exposición.Inspeccionar variables 2 comandos
Cualquier persona con acceso al contenedor puede ver las variables.
docker compose exec app env | grep PASSWORDPOSTGRES_PASSWORD=SuperSecretPassword123!
También accesible desde docker inspect.
docker inspect app --format='{{json .Config.Env}}' | jqConcepto 3 de 5
Medidas que reducen el riesgo de exposición de credenciales en proyectos con Docker.
Reduce el riesgo de incorporar credenciales al repositorio por error.
Incluya las variables requeridas sin valores, como plantilla para nuevos integrantes.
Las instrucciones ENV y ARG con valores sensibles quedan registradas en las capas de la imagen.
Utilice sustitución de variables desde .env o archivos referenciados con env_file.
ENV DATABASE_PASSWORD=SuperSecretPassword123!# Visible con: docker history mi-imagen# compose.yml: variable interpolada desde .envenvironment: - DATABASE_PASSWORD=${POSTGRES_PASSWORD}Compare dónde queda visible la misma contraseña según dónde se defina.
ENV DATABASE_PASSWORD=SuperSecretPassword123!
Peor caso: la credencial viaja con la imagen a cualquier registry y queda en el repositorio junto con el Dockerfile.
Concepto 4 de 5
Plantilla versionable que documenta las variables requeridas sin exponer valores reales.
# .env.example — Copie como .env y complete los valoresPOSTGRES_USER=POSTGRES_PASSWORD=POSTGRES_DB=APP_SECRET_KEY=.env.env.*# .env.example sí se versiona!.env.example# Estructura resultante en el repositorioproyecto/├── .env.example # versionado (plantilla)├── .env # ignorado (valores reales)├── compose.yml└── DockerfileDesactive la excepción !.env.example y observe qué ocurre con la plantilla.
.gitignore
Active o desactive cada línea. Si varias coinciden, gana la última.
Archivos del proyecto
.env.example.env.env.localcompose.ymlDockerfileConcepto 5 de 5
Un archivo .env no constituye una solución de gestión de secretos. En producción se requieren mecanismos especializados.
Soluciones de gestión de secretos
Estas herramientas ofrecen cifrado en reposo y en tránsito, control de acceso granular, rotación automática de credenciales y auditoría de uso. El estudio detallado de estas herramientas se encuentra fuera del alcance de esta lectura.
Autoevaluación
Cuatro preguntas rápidas para verificar las ideas clave de la lectura. Cada respuesta incluye una explicación.
0/4 respuestas correctas