Inicio / ConfigMap vs Secret

Diferencia entre ConfigMap y Secret en Kubernetes

La pregunta que se hace todo el mundo la primera semana con Kubernetes.

Un ConfigMap y un Secret son, estructuralmente, el mismo tipo de objeto: un mapa de pares clave-valor que un Pod puede consumir como variables de entorno o como archivos montados en un volumen. La diferencia entre ellos no está en la mecánica, sino en el propósito y el tratamiento que Kubernetes les da.

ConfigMap: configuración no sensible

Un ConfigMap se usa para datos que no comprometen nada si alguien los ve: el nivel de log, la URL de un servicio interno, el contenido de un archivo de configuración de nginx. Se guarda en texto plano dentro de etcd (la base de datos del clúster) y en la salida de kubectl get configmap -o yaml.

apiVersion: v1
kind: ConfigMap
metadata:
  name: mi-config
data:
  LOG_LEVEL: info
  APP_ENV: produccion

Secret: datos sensibles, codificados en base64

Un Secret se usa para contraseñas, tokens de API, certificados TLS o credenciales de un registro Docker privado. La diferencia técnica más visible es que los valores en el campo data se guardan codificados en base64:

apiVersion: v1
kind: Secret
metadata:
  name: mi-secret
type: Opaque
data:
  password: Y2hhbmdlbWU=

Y2hhbmdlbWU= es «changeme» codificado en base64 — no cifrado. Cualquiera que tenga permiso para leer el Secret (o que copie ese texto y lo decodifique con echo Y2hhbmdlbWU= | base64 -d) puede ver el valor original en dos segundos. La codificación en base64 existe solo para que el valor quepa en un campo YAML de texto sin problemas de caracteres especiales, no como medida de seguridad.

Entonces, ¿cómo se protege un Secret de verdad?

• RBAC: limita con Role/RoleBinding quién puede hacer get o list sobre Secrets en el namespace.
• Cifrado en reposo (encryption at rest): una configuración a nivel de clúster para que etcd no guarde los Secrets en texto plano internamente (más allá del base64).
• Gestores externos: para cargas serias, herramientas como HashiCorp Vault o los secret managers nativos de cada nube inyectan el secreto en tiempo de ejecución sin que llegue a vivir como objeto de Kubernetes.

Tipos de Secret más comunes

Opaque es el tipo genérico (pares clave-valor cualquiera). kubernetes.io/tls espera exactamente dos claves, tls.crt y tls.key, y lo usan los Ingress para servir HTTPS. kubernetes.io/dockerconfigjson guarda las credenciales de un registro Docker privado en el formato que espera el campo imagePullSecrets de un Pod.

Nuestro generador de Secrets de Kubernetes codifica los valores en base64 directamente en tu navegador —incluye los tres tipos anteriores— sin que ningún dato salga de tu equipo.

← Volver al generador