Configurar valores sensibles en Kubernetes sin ConfigMaps y Secrets abre la puerta a vulnerabilidades graves. Aprenderás a separar configuraciones de datos sensibles, crearlos desde consola y entender cuándo usar cada uno para proteger tus aplicaciones desplegadas en clúster.

¿Qué diferencia hay entre ConfigMap y Secret en Kubernetes?

Ambos objetos almacenan información que tu aplicación necesita, pero cumplen propósitos distintos. El primero guarda configuraciones en texto plano y el segundo añade una capa extra de seguridad codificando los valores en base64.

¿Qué es un ConfigMap? Es un objeto de Kubernetes que guarda configuraciones no sensibles como URLs, niveles de debug o el entorno de la aplicación (staging, desarrollo, producción) en texto plano.

¿Qué es un Secret? Es un objeto que almacena datos sensibles como API keys, contraseñas o certificados SSL, codificados en base64 para añadir fricción frente a accesos no autorizados.

La regla mental es simple: si el valor lo puedes mostrar en una captura sin riesgo, va en un ConfigMap. Si comprometería tu aplicación, va en un Secret.

¿Cómo creo un ConfigMap desde la consola?

Dentro del proyecto del curso, en la carpeta 08-configs-y-secrets, encontrarás tres archivos: uno para crear el ConfigMap, otro para el Secret y un README.md con todos los comandos de referencia [3:50].

El archivo auth_config define un objeto de tipo ConfigMap llamado auth-config con una URL como único valor. Lo aplicas de forma declarativa así:

bash kubectl apply -f auth_config.yaml

Para verificar que se creó correctamente:

• kubectl get configmap lista todos los ConfigMaps del clúster.
• kubectl describe configmap auth-config muestra el contenido en texto plano.

Un buen ejercicio es crear un ConfigMap con varios tipos de variables (strings, enteros) para configurar distintos aspectos de tu aplicación.

¿Cómo creo un Secret y por qué base64 no es cifrado?

Desde el README.md del proyecto puedes copiar el comando para crear un secreto genérico con dos variables: client_id con valor my-client-id y client_secret con valor secret [5:30].

El comando pasa los valores en texto plano por consola, lo cual no es buena práctica y se hace solo con fines educativos. Una alternativa más segura es exportar los valores como variables de entorno en Bash y referenciarlas en el comando, evitando que queden visibles.

Una vez creado, lo inspeccionas con:

• kubectl get secret para listarlos.
• kubectl describe secret auth-secret muestra el tipo opaque y el tamaño en bytes (10 bytes para client-id, 6 bytes para client-secret).
• kubectl edit secret auth-secret permite ver y editar los valores codificados.

¿Qué tan seguro es base64 en Kubernetes?

Aquí viene lo interesante: los valores no están cifrados, están codificados. Si copias el valor de client-id y lo pegas en cualquier base64 decoder online, recuperas my-client-id en segundos [7:45].

Base64 añade fricción, no seguridad real. Por eso, para entornos productivos serios necesitas herramientas externas como HashiCorp Vault o el plugin External Secrets, que conecta servicios como AWS SSM directamente con tu clúster para gestionar secretos de forma remota.

Si editas un valor en el archivo, recuerda que debes ingresarlo también codificado en base64, no en texto plano.

¿Cuándo usar ConfigMap y cuándo usar Secret?

La decisión depende exclusivamente de la sensibilidad del dato. Mezclar ambos casos es uno de los errores más comunes y costosos en Kubernetes.

Usa ConfigMap para:

• URLs de servicios externos.
• Entornos de ejecución como staging, desarrollo o producción.
• Niveles de debug como info, debug o error.
• Cualquier valor legible sin riesgo.

Usa Secret para:

• API keys de terceros.
• Contraseñas de bases de datos.
• Certificados SSL.
• Tokens de autenticación.

La precisión en esta separación marca la diferencia entre una aplicación robusta y una vulnerabilidad de seguridad en producción.

¿Qué buenas prácticas aplicar con ConfigMaps y Secrets?

Estos objetos te permiten desacoplar las configuraciones de tu aplicación, algo clave cuando manejas múltiples entornos o múltiples servicios. Puedes crear un ConfigMap por ambiente o por aplicación, y mantener todo limpio y separado.

Algunas prácticas que vale la pena adoptar desde el inicio:

1. Rota los secretos periódicamente, idealmente con automatización.
2. Aplica políticas de acceso para restringir qué usuarios o aplicaciones pueden leer cada objeto.
3. Nunca commits secretos en texto plano a un repositorio, ni siquiera codificados en base64.
4. Considera integrar HashiCorp Vault o External Secrets cuando crezca tu operación.

Kubernetes te da las herramientas, pero la disciplina la pones tú. ¿Cómo integrarías estos ConfigMaps y Secrets dentro de tus pods o deployments? Investígalo y déjame en los comentarios qué encontraste.