En la práctica, los equipos que ya usan Kubernetes con service mesh suelen inclinarse por mTLS interno y reservan JWT para las llamadas que llegan desde clientes externos o desde aplicaciones legacy que no pueden soportar certificados.

API Gateway, rate limiting y políticas de acceso centralizadas

Colocar un API Gateway como Kong, Traefik o AWS API Gateway delante de los microservicios sigue siendo la opción más extendida para el tráfico norte-sur. El gateway se encarga de validar tokens, aplicar rate limiting por cliente y transformar payloads antes de que lleguen al primer servicio.

El rate limiting debe ser granular. No basta con limitar por IP; es necesario limitar por client_id, por usuario final y por ruta. Kong con el plugin rate-limiting-advanced permite definir políticas distintas para cada servicio y almacenar contadores en Redis con persistencia. Esa configuración evita que un solo servicio mal programado pueda saturar todo el clúster.

Patrones de rate limiting que funcionan en producción

1. Token bucket por client_id con burst de 200 peticiones y refill de 50 por segundo para endpoints públicos.
2. Sliding window por usuario final para operaciones sensibles como cambios de contraseña o transferencias.
3. Rate limiting por servicio origen cuando el tráfico viene de otros microservicios internos para evitar cascadas.

Además del gateway, muchos equipos están adoptando Open Policy Agent (OPA) como motor de políticas centralizado. OPA permite escribir reglas en Rego que se evalúan en cada petición sin necesidad de modificar el código de los microservicios. Una regla típica verifica que el scope del token coincida con la acción solicitada y que el servicio origen esté en la lista blanca para ese endpoint.

Observabilidad, detección de anomalías y respuesta a incidentes

La seguridad de APIs en microservicios no termina en la autenticación. Necesitas visibilidad de lo que realmente está pasando en cada llamada. Herramientas como OpenTelemetry combinadas con Jaeger o Tempo permiten trazar el recorrido completo de una petición a través de decenas de servicios y detectar patrones anómalos.

Una práctica que está dando buenos resultados es enviar todos los eventos de autorización a un sistema de streaming (Kafka o Pulsar) y aplicar reglas de detección en tiempo real con herramientas como Falco o custom jobs en Spark. De esta forma se puede identificar, por ejemplo, que un servicio está haciendo llamadas a endpoints que nunca había usado antes o que está solicitando scopes excesivos.

Elementos mínimos de logging y métricas para APIs

• Registrar siempre el client_id, el scope solicitado, el código de respuesta y la latencia de cada petición, nunca el payload completo.
• Generar métricas Prometheus con etiquetas de servicio origen, servicio destino y código HTTP para detectar picos de errores 401 y 403.
• Conservar traces distribuidos durante al menos 30 días en entornos de producción para poder investigar incidentes con calma.
• Configurar alertas cuando el ratio de peticiones fallidas por autenticación supere el 5 % durante más de cinco minutos.

Ejemplos reales de implementaciones en empresas hispanohablantes

Una fintech mexicana que procesa más de 180 millones de transacciones mensuales migró su monolito a microservicios en 2022. Tras sufrir dos incidentes de abuso de API en seis meses, implementó mTLS con Istio en el clúster de Kubernetes y OPA para todas las políticas de autorización. El resultado fue una reducción del 94 % en intentos de acceso no autorizado y una latencia media adicional de solo 7 ms por petición.

Otro caso documentado es el de una empresa española de logística con más de 40 microservicios. Decidieron mantener JWT para el tráfico externo y usar mTLS únicamente entre servicios internos. Configuraron Kong con rate limiting por client_id y enviaron todos los eventos de autorización a un topic de Kafka.

En los primeros nueve meses detectaron tres patrones de abuso que antes pasaban desapercibidos, uno de ellos originado por un servicio interno que había sido comprometido mediante una vulnerabilidad en una dependencia.

Un banco colombiano que opera con más de 120 microservicios optó por una solución híbrida: API Gateway con Kong para el tráfico público y Linkerd con mTLS para el tráfico interno. Además integraron Falco para detectar comportamientos anómalos en los pods. El equipo de seguridad reportó que el tiempo medio de detección de incidentes bajó de 11 días a menos de 4 horas.

Errores frecuentes que siguen cometiendo los equipos

Uno de los fallos más repetidos es dejar los endpoints de healthcheck y métricas sin protección. Muchos servicios exponen /health y /metrics sin autenticación porque “son solo datos internos”, pero en entornos con service mesh esos endpoints quedan accesibles desde cualquier pod de la red.

Otro error habitual es reutilizar el mismo token JWT para todos los servicios sin validar el claim de audiencia. Un servicio que solo debería leer datos termina pudiendo modificar recursos porque el token fue emitido con scopes demasiado amplios.

Finalmente, muchos equipos subestiman el impacto del almacenamiento de secretos. Usar variables de entorno para guardar claves privadas de JWT o certificados mTLS es una práctica que sigue siendo muy común y que facilita enormemente la exfiltración cuando un contenedor se ve comprometido.

Perspectiva a medio plazo y herramientas que están madurando

La tendencia clara es que el service mesh se convertirá en la capa de seguridad por defecto para el tráfico interno, mientras que el API Gateway seguirá siendo el punto de entrada para clientes externos. Herramientas como SPIRE para emisión de certificados y OPA para políticas declarativas están ganando adopción porque reducen la cantidad de código que los desarrolladores tienen que mantener.

En paralelo, proyectos como eBPF están permitiendo aplicar políticas de red y observabilidad con un overhead inferior al 2 % en muchos casos. Esto abre la puerta a inspeccionar el tráfico a nivel de kernel sin necesidad de modificar las aplicaciones ni añadir sidecars pesados.

La pregunta ¿cómo optimizar API security en microservicios? no tiene una respuesta única que valga para todos los entornos. Depende del número de servicios, del nivel de cumplimiento normativo requerido, de la latencia que se pueda asumir y de si ya se cuenta con un service mesh en producción.

Lo que sí es común en todas las implementaciones exitosas es que la seguridad se trata como una propiedad de la plataforma, no como una responsabilidad que cada equipo de servicio debe resolver por su cuenta.

Los equipos que han logrado mantener un equilibrio razonable entre seguridad y velocidad de desarrollo suelen tener tres cosas en común: políticas centralizadas que no requieren cambios en el código de los microservicios, observabilidad suficiente para detectar anomalías en horas en lugar de días, y una rotación automática de credenciales que elimina la necesidad de gestionar secretos manualmente. Esa combinación, aplicada con criterio, es lo que realmente marca la diferencia en entornos de microservicios a escala.