La regla de oro: config fuera del código

Una aplicación lista para producción nunca lleva sus valores de configuración dentro de la imagen. Cambiar una URL, una clave o un feature flag no debería obligarte a reconstruir y redeployar. Kubernetes ofrece dos objetos para separar configuración del código: ConfigMap y Secret.

ConfigMap: valores no sensibles

Un ConfigMap es un objeto que guarda pares clave-valor en texto plano. Úsalo para cosas como URLs de APIs, nombres de buckets, modos de entorno o archivos de configuración enteros. No lo uses para contraseñas ni tokens.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: production
  API_URL: https://api.midominio.com
  LOG_LEVEL: info

Secret: credenciales y datos sensibles

Un Secret se ve casi igual, pero está pensado para datos sensibles: contraseñas, tokens JWT, claves privadas, certificados. Los valores se guardan codificados en base64. Es importante entender que base64 no es cifrado: cualquier persona con acceso a la API de Kubernetes puede decodificarlo. Lo único que obtiene es no aparecer en claro a simple vista.

apiVersion: v1
kind: Secret
metadata:
  name: db-creds
type: Opaque
stringData:
  DB_USER: app
  DB_PASSWORD: sup3rS3cret0

Usa stringData para escribirlos en texto y que Kubernetes los codifique por ti.

Dos formas de consumirlos en un Pod

Como variables de entorno

env:
  - name: APP_ENV
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: APP_ENV
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-creds
        key: DB_PASSWORD

O más corto con envFrom para inyectar todas las claves de un golpe.

Como archivos montados en un volumen

volumes:
  - name: config-vol
    configMap:
      name: app-config
volumeMounts:
  - name: config-vol
    mountPath: /etc/app/config

Cada clave aparece como un archivo dentro del directorio. Esta forma es ideal cuando tu aplicación espera leer un application.yml, un nginx.conf o un certificado completo.

Buenas prácticas

• Nunca metas secretos dentro de la imagen Docker ni de un ConfigMap.
• No los subas a Git en claro. Usa herramientas como sealed-secrets, SOPS o el External Secrets Operator para versionarlos cifrados.
• Activa encryption at rest en etcd para que los Secrets no queden en disco en base64 plano.
• Limita con RBAC quién puede leer Secrets: por defecto casi todo mundo puede.
• Usa un Secret distinto por entorno (dev, staging, prod) y por componente. No acumules todo en uno gigante.
• Para certificados TLS, usa el tipo específico kubernetes.io/tls en vez de Opaque.

Cuando cambias un valor

Un matiz importante: si actualizas un ConfigMap o Secret, los Pods que ya lo leyeron como variables de entorno no ven el cambio hasta que se reinicien. Si lo montas como archivo, Kubernetes sí propaga los cambios al filesystem después de unos segundos, aunque tu aplicación debe saber recargar esos archivos. Una práctica común es forzar el rollout del Deployment cuando cambie la config, para asegurar que todos los Pods arranquen con la versión nueva.

Resumen

ConfigMaps y Secrets son el camino correcto para externalizar configuración en Kubernetes. Piensa en ConfigMaps como tu .env y en Secrets como tu .env.secret, pero con la ventaja de poder compartirlos entre varios Pods, versionarlos y rotarlos sin tocar las imágenes.