Tema 12
En microservicios no basta con que los componentes existan: también deben encontrarse, configurarse y adaptarse en tiempo de ejecución. Ese proceso mejora escalabilidad y flexibilidad, pero introduce nuevas superficies de ataque si el descubrimiento de servicios o la configuración se diseñan sin controles claros.
En un sistema monolítico la ubicación de los componentes suele ser relativamente fija. En microservicios eso cambia. Los servicios se escalan, se recrean, se distribuyen entre nodos, cambian de instancia y se despliegan en entornos dinámicos. Para que la plataforma funcione, los componentes necesitan mecanismos para descubrir a otros servicios y obtener su configuración de manera consistente.
Esto aporta elasticidad y simplifica operación, pero también crea puntos sensibles. Un registro de servicios alterado, una configuración mal distribuida o un endpoint interno accidentalmente expuesto pueden afectar disponibilidad, integridad o confidencialidad del sistema completo.
Por eso el descubrimiento de servicios y la configuración centralizada deben considerarse parte del diseño de seguridad, no simples detalles de infraestructura.
Service discovery es el mecanismo por el cual un componente puede localizar a otro sin depender de direcciones estáticas preconfiguradas. En lugar de codificar IPs o rutas rígidas, los servicios consultan un registro, una capa de plataforma o un sistema de resolución que les indica dónde está disponible el destino.
Esto es esencial en entornos con escalado dinámico y despliegues frecuentes, pero introduce una dependencia de confianza: si el mecanismo de descubrimiento falla o es manipulado, el tráfico puede desviarse, interrumpirse o dirigirse hacia destinos no esperados.
La configuración centralizada busca evitar que cada servicio tenga parámetros dispersos, manuales o inconsistentes en cada instancia. En su forma madura, permite distribuir parámetros operativos de manera controlada, versionada y observable.
Esa configuración puede incluir:
| Capacidad | Qué mejora | Riesgo si se gestiona mal |
|---|---|---|
| Discovery dinámico | Escalado y reemplazo transparente de instancias | Desvío de tráfico o dependencia ciega del registro |
| Config centralizada | Consistencia entre instancias y entornos | Propagación rápida de errores o configuraciones inseguras |
| Feature flags | Control gradual de comportamiento | Exposición accidental de funciones o bypass de controles |
Un sistema de discovery mal protegido puede convertirse en una fuente crítica de riesgo. Si cualquier actor puede registrar servicios, modificar metadatos o consultar todo el mapa interno, la arquitectura pierde control sobre su topología y su confianza interna.
Muchos sistemas distribuidos utilizan etiquetas, metadatos o atributos de servicio para routing, políticas o decisiones operativas. Eso puede ser útil, pero también peligroso si esos metadatos se consumen sin validar su origen o sin controlar quién puede modificarlos.
Un metadato aparentemente inocente puede terminar influyendo en:
Uno de los errores más frecuentes es usar el sistema de configuración para almacenar secretos sensibles como contraseñas, claves o tokens. Aunque técnicamente sea cómodo, desde el punto de vista de seguridad suele ser una mala decisión.
La configuración operativa y los secretos tienen necesidades distintas:
Centralizar configuración mejora consistencia, pero también aumenta el impacto de un error. Una mala política, un valor mal tipeado o una bandera activada incorrectamente puede afectar simultáneamente a muchos servicios o instancias.
Por eso conviene diseñar con estas preguntas:
Las feature flags son valiosas para habilitar funciones de forma gradual, pero también pueden introducir riesgo si controlan capacidades sensibles. Una mala bandera puede abrir endpoints no listos, alterar flujos de autorización o dejar visible una funcionalidad administrativa.
Cuando una flag impacta seguridad o exposición, conviene tratarla con el mismo cuidado que una política operativa crítica.
La configuración y el discovery no deberían operar como cajas negras de cambios manuales. Necesitan trazabilidad, revisión y gobierno. Si no se puede responder quién cambió una ruta, cuándo se modificó un parámetro sensible o qué versión de configuración estaba activa durante un incidente, la operación se vuelve opaca.
Si el sistema de configuración central o el mecanismo de discovery caen, muchos servicios pueden quedar degradados o imposibilitados de arrancar. Por eso la seguridad también debe contemplar disponibilidad de estas piezas.
Una arquitectura madura evalúa:
En microservicios, encontrar servicios y distribuir configuración de forma dinámica es casi inevitable. La cuestión no es evitarlo, sino hacerlo con límites claros, fuentes de verdad confiables y controles de acceso apropiados. Cuando discovery y configuración se diseñan bien, aumentan resiliencia y velocidad; cuando se diseñan mal, se convierten en multiplicadores silenciosos del riesgo.
En el próximo tema estudiaremos comunicación síncrona y asíncrona, resiliencia, timeouts y circuit breakers para analizar cómo las decisiones de interacción influyen en seguridad y estabilidad del sistema.