Introducción
Cortex, el proyecto CNCF para almacenamiento a largo plazo y multi-tenant de métricas de Prometheus y trazas de OpenTelemetry, completó una auditoría de seguridad financiada por el Open Source Technology Improvement Fund (OSTIF). El análisis, realizado por Quarkslab en marzo de 2026, se centró en la integridad del aislamiento entre tenants y la seguridad de las operaciones a nivel cluster. Los hallazgos incluyen 7 vulnerabilidades que ya fueron corregidas por el equipo de maintainers.
Qué ocurrió
Entre marzo y abril de 2026, dos auditores de Quarkslab evaluaron el posture de seguridad de Cortex mediante un enfoque de whitebox. El proceso consistió en cuatro fases: discovery (mapeo de la arquitectura y componentes), análisis del modelo de amenazas preexistente, revisión estática de código (con herramientas de análisis automático) y pruebas dinámicas. El foco prioritario fue validar la confidencialidad, integridad y disponibilidad de dos áreas críticas: el boundary entre tenants (evitar que un tenant acceda a datos de otro) y las operaciones de cluster (como escalado, backups o actualizaciones).
El resultado fue un informe con 7 hallazgos, todos clasificados como de severidad media. Según la publicación oficial del CNCF, no se detectaron vulnerabilidades críticas o altas, pero los issues identificados podrían permitir ataques como cross-tenant data access en escenarios específicos o afectar la disponibilidad del servicio.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos que despliegan Cortex en producción —especialmente en entornos multi-tenant—, estas vulnerabilidades representaban riesgos concretos. Un exploit exitoso de los issues de aislamiento podría permitir que un tenant malintencionado accediera a métricas o trazas de otros tenants, violando el principio de multi-tenancy. En arquitecturas con clusters compartidos (común en proveedores de observabilidad managed), esto se traduce en un riesgo de fugas de datos entre clientes.
En cuanto a las operaciones de cluster, los hallazgos afectaban componentes como el ingester (responsable de escribir datos) y el compactor (encargado de compactar bloques de almacenamiento). Una explotación podría causar denegación de servicio (DoS) o corrupción de datos, impactando la disponibilidad del sistema de observabilidad. Dado que Cortex es usado por organizaciones que escalan Prometheus a millones de series de métricas, un incidentes de este tipo tendría efectos en cascada sobre la monitorización de servicios críticos.
El CVSS base de los hallazgos no fue público, pero el CNCF destacó que todas las vulnerabilidades fueron parcheadas antes de la divulgación. Esto reduce el riesgo actual, pero los equipos deben actualizar urgentemente si ejecutan versiones afectadas.
Detalles técnicos
El informe completo (disponible aquí) no revela los detalles técnicos de las vulnerabilidades para evitar exponer información sensible antes de que la mayoría de los usuarios se actualicen. Sin embargo, el fix response publicado por el equipo de Cortex y Quarkslab proporciona contexto sobre las áreas afectadas:
- Aislamiento de tenants:
– Issues en el ruler (motor de alertas y rules), donde las reglas definidas por un tenant podían afectar a otros tenants si se usaban nombres de series no sanitizados.
- Operaciones de cluster:
– Falta de autenticación en endpoints internos del compactor, accesibles desde otros pods del mismo namespace en clusters Kubernetes.
– Problemas de manejo de recursos en el distributor (recibe samples de Prometheus), que permitían un ataque de resource exhaustion mediante requests maliciosos.
Las versiones afectadas no fueron especificadas, pero el equipo de Cortex indicó que todas las correcciones están incluidas en la release v1.15.0 (lanzada en julio de 2026). Los commits con los fixes pueden revisarse en el repositorio cortexproject/cortex bajo los milestones Security Audit 2026.
Qué deberían hacer los administradores y equipos técnicos
- Actualizar Cortex:
helm upgrade cortex cortex-helm/chart --namespace monitoring --values values.yaml
– Para servicios managed (como Grafana Cloud o Cortex Operator), verificá que el proveedor ya haya aplicado los parches. Grafana anunció que todas las instancias de Cortex en su plataforma fueron actualizadas el 20 de julio de 2026.
- Revisar la configuración:
--multi-tenancy=true esté habilitado (es el valor por defecto en v1.15.0+). Si se usa single-tenant, evaluar si esta decisión es intencional.– Verificar que los endpoints internos (puertos 8081, 8082) no estén expuestos públicamente. En Kubernetes, usá NetworkPolicies para restringir el acceso:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: restrict-cortex-internal
spec:
podSelector:
matchLabels:
app.kubernetes.io/name: cortex
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app.kubernetes.io/name: cortex
ports:
- protocol: TCP
port: 8081
- protocol: TCP
port: 8082
- Monitorear actividad sospechosa:
.* o {.*}), que podrían indicar intentos de exfiltrar datos entre tenants.– Revisar los logs del ruler en busca de errores de permisos al evaluar rules.
- Participar de la comunidad:
– Reportar cualquier issue de seguridad a [email protected], siguiendo el proceso de responsible disclosure del proyecto.
Conclusión
La auditoría de Cortex es un ejemplo de cómo los proyectos de cloud native maduros priorizan la seguridad proactiva. Si bien las 7 vulnerabilidades encontradas no eran críticas, su corrección fortalece el aislamiento entre tenants y la resiliencia del cluster, dos pilares para usar Cortex en entornos de producción con requisitos estrictos de seguridad. Para los equipos que ya ejecutan Cortex, la acción inmediata es actualizar a v1.15.0 y revisar la configuración. Quienes evalúen adoptarlo pueden hacerlo con mayor confianza, sabiendo que el proyecto ha sido sometido a un escrutinio riguroso por auditores externos.