Ir al contenido

Conceptos 05 - Credenciales y datos sensibles

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.

  • 5 conceptos
  • 4 elementos interactivos
  • Autoevaluación final

Concepto 1 de 5

El problema de las contraseñas en texto plano

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 plano
POSTGRES_USER=admin
POSTGRES_PASSWORD=SuperSecretPassword123!
API_KEY=sk-live-a1b2c3d4e5f6g7h8i9j0
JWT_SECRET=my-jwt-secret-key-2024

Si 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 Dockerfile

Versió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

Limitaciones del uso de .env

Aceptable en desarrollo, pero con limitaciones importantes que conviene conocer.

  • Los valores permanecen visibles en texto plano para cualquier persona con acceso al archivo.
  • Las variables pueden inspeccionarse dentro del contenedor con env o mediante docker inspect.
  • Un archivo .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!

Concepto 3 de 5

Buenas prácticas iniciales

Medidas que reducen el riesgo de exposición de credenciales en proyectos con Docker.

Agregue .env a .gitignore

Reduce el riesgo de incorporar credenciales al repositorio por error.

Proporcione un archivo .env.example

Incluya las variables requeridas sin valores, como plantilla para nuevos integrantes.

No incorpore credenciales en el Dockerfile

Las instrucciones ENV y ARG con valores sensibles quedan registradas en las capas de la imagen.

No incluya credenciales directamente en compose.yml

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 .env
environment:
- DATABASE_PASSWORD=${POSTGRES_PASSWORD}

Compare dónde queda visible la misma contraseña según dónde se defina.

ENV DATABASE_PASSWORD=SuperSecretPassword123!
  • Repositorio GitVisibleCualquiera con acceso al repositorio o a su historial
  • Capas de la imagenVisibledocker history mi-imagen
  • Entorno del contenedorVisibledocker compose exec app env · docker inspect
  • Archivo .env localNo visibleTexto plano para quien tenga acceso al equipo o reciba el archivo

Peor caso: la credencial viaja con la imagen a cualquier registry y queda en el repositorio junto con el Dockerfile.

Concepto 4 de 5

Ejemplo de .env.example

Plantilla versionable que documenta las variables requeridas sin exponer valores reales.

# .env.example — Copie como .env y complete los valores
POSTGRES_USER=
POSTGRES_PASSWORD=
POSTGRES_DB=
APP_SECRET_KEY=
.gitignore
.env
.env.*
# .env.example sí se versiona
!.env.example
# Estructura resultante en el repositorio
proyecto/
├── .env.example # versionado (plantilla)
├── .env # ignorado (valores reales)
├── compose.yml
└── Dockerfile

Desactive 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.local
  • compose.yml
  • Dockerfile

Concepto 5 de 5

Más allá de .env en producción

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

  • Docker Secrets (modo Swarm)
  • HashiCorp Vault
  • AWS Secrets Manager
  • Google Secret Manager
  • Azure Key Vault

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

Comprueba lo que aprendiste

Cuatro preguntas rápidas para verificar las ideas clave de la lectura. Cada respuesta incluye una explicación.

  1. 1Se subió un .env con contraseñas al repositorio y en el commit siguiente se eliminó. ¿Qué medida resuelve el problema de forma definitiva?
  2. 2Las credenciales se inyectan desde un .env que no se versiona. ¿Dónde siguen siendo visibles?
  3. 3¿Por qué no se debe definir una contraseña con ENV en el Dockerfile?
  4. 4¿Para qué sirve versionar un archivo .env.example?

0/4 respuestas correctas