ConfigMaps y Secrets en Kubernetes: límites de tamaño, propagación de actualizaciones y lo que un Secret no protege

Qué es

Un ConfigMap contiene datos clave-valor no confidenciales; un Secret contiene una pequeña cantidad de datos sensibles. Ambos son consumidos por los Pods como variables de entorno, como argumentos de línea de comandos a través de esas variables, o como archivos en un volumen montado. La documentación de ConfigMap (citada) afirma que un ConfigMap no está diseñado para contener grandes bloques de datos y que sus datos no pueden superar 1 MiB; la documentación de Secret (citada) fija el mismo límite de 1 MiB por Secret. Ambos objetos pueden marcarse como immutable, tras lo cual sus datos ya no pueden cambiarse y el kubelet deja de vigilarlos.

Por qué importa

Dos propiedades se malinterpretan habitualmente. Primero, la propagación de actualizaciones: según la documentación citada, un ConfigMap consumido en un volumen finalmente se actualiza tras la sincronización periódica del kubelet más su retraso de propagación de caché, mientras que los ConfigMaps consumidos como variables de entorno no se actualizan automáticamente y requieren reiniciar el Pod, y un contenedor que monta un ConfigMap mediante subPath nunca recibe actualizaciones. Segundo, el secreto: los Secrets se almacenan, de forma predeterminada, sin cifrar en etcd; cualquiera con acceso a la API puede recuperar o modificar un Secret, cualquiera con acceso a etcd puede leerlo, y cualquiera que pueda crear un Pod en un namespace puede leer todos los Secrets de ese namespace a través de ese Pod. Base64 es una codificación, no una protección.

Cómo aplicarlo

• Mantener en la imagen o en el manifiesto la configuración que cambia con cada versión, y colocar en los ConfigMaps solo los valores específicos del entorno; versionar los archivos grandes en otro lugar.
• Montar como volumen sin subPath cuando la aplicación pueda releer los archivos; en caso contrario, provocar un rollout ante cada cambio, por ejemplo incorporando un hash del ConfigMap en una anotación del Pod para que cambie la plantilla del Deployment.
• Seguir los pasos que enumera la documentación de Secret: habilitar el cifrado en reposo para los Secrets, escribir reglas de RBAC que concedan get sobre los Secrets únicamente a las cuentas de servicio que los necesiten, restringir el acceso a los Secrets a contenedores específicos, y considerar un almacén de secretos externo.
• Marcar como immutable los ConfigMaps y Secrets ligados a una versión, y crear un objeto nuevo por versión; esto también reduce la carga de observación (watch) en el API server.
• No imprimir nunca los objetos Secret en la salida de CI: kubectl get secret -o yaml muestra la forma en base64, que se decodifica trivialmente (kubectl describe oculta los valores y solo muestra sus tamaños).

Trampas

Alcance de namespace: un Pod solo puede hacer referencia a Secrets de su propio namespace. La página de tareas de ConfigMap (citada) indica que un ConfigMap o clave referenciados que no existen impiden que el Pod se inicie, a menos que la referencia esté marcada como optional; el mismo campo optional existe para las referencias a Secrets. Las variables de entorno son heredadas por todos los procesos hijos y tienden a terminar en la salida de diagnóstico; los archivos con permisos restrictivos son la proyección más segura para las credenciales.