¿Cómo funcionan los ConfigMaps y Secrets para inyectar configuración en los workloads?

Question

IT Interview Practice · Accepted Answer

Los **ConfigMaps** y **Secrets** desacoplan la configuración de las imágenes de contenedor, de modo que la misma imagen corre en dev, staging y producción con ajustes distintos. Los ConfigMaps guardan config **no sensible**; los Secrets guardan datos **sensibles** (contraseñas, tokens, claves) y se manejan con más cuidado.

## La idea: la config fuera de la imagen

```text
Imagen = código (inmutable, construido una vez).  Config = valores por entorno.
Incrustar la config en la imagen es un anti-patrón (reconstruir por entorno, fugas de secrets).
→ Guarda la config en ConfigMaps/Secrets, inyéctala en runtime como env vars o ficheros.
```

## ConfigMap: ajustes no sensibles

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  FEATURE_X: "true"
  app.properties: |
    timeout=30
    retries=3
```

## Secret: valores sensibles

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # texto plano aquí; se almacena codificado en base64 en etcd
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# Normalmente se crea de forma imperativa para no subir secrets a git:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Inyectar en un Pod: como env vars o como ficheros

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # una sola clave de un ConfigMap
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # una sola clave de un Secret
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # importa TODAS las claves como env vars
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # monta la config como ficheros
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Advertencias importantes sobre los Secrets

```text
⚠ Por defecto, los datos de un Secret están CODIFICADOS en base64, no cifrados.
  → Habilita el CIFRADO EN REPOSO para etcd (EncryptionConfiguration).
  → Restringe el acceso con RBAC (quién puede 'get secrets').
  → Prefiere gestores externos (Vault, Secrets Manager del cloud) o sealed secrets.
  → Nunca subas manifests de Secret reales a git.
La config por env var se lee UNA VEZ al arrancar el contenedor; los ficheros montados pueden actualizarse en vivo.
```

## Por qué es importante

Separar la configuración del código es una práctica operativa central, y los ConfigMaps y Secrets son la forma en que Kubernetes la implementa, así que entenderlos es conocimiento esencial de nivel medio. Incrustar ajustes específicos de un entorno en una imagen es un anti-patrón —obliga a reconstruir por entorno y arriesga fugas de secrets—, así que Kubernetes te permite mantener una única imagen inmutable e inyectar la configuración en runtime: **ConfigMaps** para valores no sensibles (niveles de log, feature flags, ficheros de config) y **Secrets** para datos sensibles (contraseñas, tokens, claves). Conocer las dos formas de consumirlos —como **variables de entorno** (claves individuales vía `configMapKeyRef`/`secretKeyRef`, o todas las claves vía `envFrom`) y como **ficheros montados** (con el matiz de que las env vars se leen una vez al arrancar mientras que los ficheros montados pueden actualizarse en vivo)— es conocimiento práctico de uso diario para desplegar aplicaciones reales. Igual de importante es entender las advertencias de seguridad que tropiezan a muchos ingenieros: por defecto los datos de un Secret solo están **codificados en base64, no cifrados**, así que protegerlos de verdad requiere habilitar el **cifrado en reposo** para etcd, restringir el acceso con **RBAC**, evitar subir manifests de Secret al control de versiones y, a menudo, integrar un gestor de secrets externo. Como prácticamente todo workload necesita configuración y credenciales por entorno, y como manejar mal los Secrets es una brecha de seguridad común y grave, un buen dominio de los ConfigMaps y Secrets es fundamental para ejecutar aplicaciones de forma segura y correcta en Kubernetes.

La idea: la config fuera de la imagen

ConfigMap: ajustes no sensibles

Secret: valores sensibles

Inyectar en un Pod: como env vars o como ficheros

Advertencias importantes sobre los Secrets

Por qué es importante

Preguntas relacionadas