Proxy TCP

Microservicios y Kubernetes: un proxy por base de datos o un sidecar por pod

Con muchos servicios, cada uno con su propio acceso a la base, es difícil saber qué SQL llega a producción. El proxy TCP de Vericto se despliega dentro del clúster, como un servicio compartido delante de cada base de datos o como un sidecar junto a cada servicio, y aplica las mismas reglas a todo el tráfico, en cualquier lenguaje.

Empezar gratis Desplegar el proxy en Kubernetes
Diagrama: microservicios en Kubernetes con el proxy de VerictoDentro de un clúster de Kubernetes, los servicios orders-api y catalog-api se conectan a un proxy de Vericto compartido, un Deployment con dos réplicas y su Service, que evalúa cada sentencia antes de orders-db en PostgreSQL. Abajo, el servicio payments-api tiene el proxy como sidecar en su pod, en localhost:5433, delante de payments-db en MySQL. El proxy recibe las reglas de Vericto Cloud y le envía la telemetría.Clúster de KubernetesPod con sidecarpermitidapermitidareglas · telemetríaorders-apicatalog-apiProxy compartidoDeployment, 2 réplicasEvalúa aquíorders-dbPostgreSQLpayments-apiProxy sidecarlocalhost:5433Evalúa aquípayments-dbMySQLVericto Cloudreglas y audit trailDiagrama: microservicios en Kubernetes con el proxy de VerictoDentro de un clúster de Kubernetes, los servicios orders-api y catalog-api se conectan a un proxy de Vericto compartido, un Deployment con dos réplicas y su Service, que evalúa cada sentencia antes de orders-db en PostgreSQL. Abajo, el servicio payments-api tiene el proxy como sidecar en su pod, en localhost:5433, delante de payments-db en MySQL. El proxy recibe las reglas de Vericto Cloud y le envía la telemetría.Clúster de KubernetesPod con sidecarreglas · telemetríaVericto Cloudreglas y audit trailorders-apicatalog-apiProxy compartidoDeployment, 2 réplicasEvalúa aquíorders-dbPostgreSQLpayments-apiProxy sidecarlocalhost:5433Evalúa aquípayments-dbMySQL
  • Ruta de la sentencia SQL
  • Vericto Cloud: reglas y telemetría
  • Donde Vericto evalúa
Dos patrones en el mismo clúster: arriba, un proxy compartido por los servicios que usan orders-db; abajo, un sidecar dentro del pod de payments-api. Cada proxy sincroniza sus reglas con Vericto Cloud.

Qué protege

Las mismas reglas y las mismas políticas para todos los servicios que usan una base, sin una librería por lenguaje:

  • VERICTO-001, 042, 010 y 011: DELETE y UPDATE sin WHERE, DROP TABLE y TRUNCATE, venga del servicio que venga.
  • VERICTO-015 a 019: DDL riesgoso en runtime, como ALTER TABLE … DROP COLUMN o desactivar triggers y RLS.
  • VERICTO-087 (Team y Enterprise): una allowlist de tablas y columnas por identidad. En el proxy, la identidad es el usuario de base de datos de la sesión: da a cada servicio su propio usuario y su propia allowlist.
  • VERICTO-085 (Team y Enterprise): columnas sensibles bloqueadas o enmascaradas en el resultado, para todos los servicios a la vez.

Latencia y disponibilidad

Con un sidecar, el salto entre el servicio y el proxy es localhost dentro del pod. Con un proxy compartido, es un salto más dentro del clúster. En los dos casos, el parsing y la evaluación ocurren en el proceso del proxy, sin llamadas de red en la ruta crítica.

Para el parsing y la evaluación de reglas, el objetivo de diseño es p99 < 2 ms. Es un objetivo, no una medición: el benchmark de latencia del proxy todavía no está publicado.

Tamaños recomendados: de 0,25 vCPU y 64 MB (hasta 1.000 queries por segundo) a 1 vCPU y 256 MB (50.000 o más). La memoria crece con las conexiones, unos 4 KB por sesión TCP: un sidecar por pod multiplica instancias pequeñas; un proxy compartido concentra el tráfico de una base en pocas réplicas.

Cómo implementarlo

  1. Registra cada base de datos y crea una API key con rules:read y telemetry:write. Guárdala como Secret de Kubernetes.
  2. Proxy compartido: un Deployment con dos réplicas y un Service por base de datos (el manifiesto está en la guía). Los servicios apuntan su connection string a vericto-proxy:5433.
  3. Sidecar: agrega el contenedor ghcr.io/vericto/vericto-proxy al pod y conecta el servicio a localhost:5433. Dentro del pod, el TLS entre la aplicación y el proxy puede quedar deshabilitado.
  4. Si la base es gestionada (RDS, Cloud SQL), cifra el salto proxy → base con UPSTREAM_SSLMODE=require o verify-full: TLS.
  5. Si el audit trail no puede perder eventos, usa VERICTO_TELEMETRY_BUFFER=disk con un volumen persistente: buffering de telemetría.
  6. Da a cada servicio su propio usuario de base de datos, para ver y limitar su tráfico por separado. En ECS (Fargate), la guía trae la task definition.

Cuándo no usar esta opción

  • Servicios sobre Oracle o SQL Server. Usa la API de runtime, con su límite de seguridad de 100 solicitudes por segundo por API key (se puede subir si lo necesitas).
  • Un service mesh con TLS de extremo a extremo hasta la base. El proxy necesita ver el SQL: el TLS del cliente debe terminar en el proxy (PROXY_TLS_MODE=require) y volver a abrirse hacia la base.
  • Una sola aplicación y una sola base. No necesitas nada de esto: ver aplicación web.

Disponibilidad por plan

FunciónFreeBuilderTeamEnterprise
Proxy TCP, API de runtime, CLI y MCPSíSíSíSí
Queries al mes (proxy y API de runtime)500K5M50MIlimitadas
Bases de datos1310A medida
Allowlists por agente (VERICTO-087)——SíSí
Columnas sensibles y enmascaramiento (VERICTO-085)——SíSí
Simulador de reglas—Hasta 30 díasHasta 90 díasSegún contrato (hasta 180 días)
Despliegue en tu VPC———Sí

Precios y todos los límites en Precios.

Pruébalo con tu propio SQL

El plan Free incluye 500K queries al mes y 1.000 validaciones de CLI y MCP, sin tarjeta de crédito. Para despliegues en tu VPC, SSO y SLA dedicados, habla con ventas.

Empezar gratis Hablar con ventas