Kong Proxy
A kong proxy sits in front of your backend web services and routes client requests. You set it up by defining upstream services, public routes, and traffic plugins. Engineering teams use this tool to manage external API traffic in one central place. Still, teams often grant broad network permissions to the routing nodes during setup. When a route has broad permissions, any valid caller can reach deep into backend systems. This creates risk when developers or internal tools use shared keys to run
Database Proxy (ProxySQL, PgBouncer) + Kong Security Plugins: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A kong proxy sits in front of your backend web services and routes client requests. You set it up by defining upstream services, public routes, and traffic plugins. Engineering teams use this tool to manage external API traffic in one central place. Still, teams often grant broad network permissions to the routing nodes during setup. When a route has broad permissions, any valid caller can reach deep into backend systems. This creates risk when developers or internal tools use shared keys to run admin tasks.
How a kong proxy routes and filters traffic
The core architecture relies on two main parts: a control plane and a data plane. Admins send setup rules to the control plane through an admin interface or state file. The data plane nodes read these rules and listen for incoming web traffic from clients. Each incoming call hits a defined route based on the host, path, or method. The route then points the traffic to a specific backend service object in the system.
Before the request reaches the backend, the system runs a set of attached plugins. Teams attach these plugins to global traffic, specific routes, or single consumer profiles. A plugin can check an API key, verify a token, or count request rates. If the caller passes these checks, the node forwards the call to the upstream server. When the backend server replies, the node sends the response back to the client. It also writes basic metadata about the call to an external log sink.
Managing plugins and upstream service rules
Teams often group multiple backend server addresses under a single upstream entity for load balancing. The routing node checks the health of each server target on a steady timer. If one backend server fails a health check, the node stops sending traffic there. When the server recovers, the system adds it back into the active rotation pool. This setup keeps public web apps online even when single backend hosts fail.
Admins also use consumer objects to track different external apps or partner teams. You link a consumer to a key or token plugin to enforce rate limits. This prevents one noisy client from using up all available backend compute capacity. Still, managing hundreds of consumer keys across many routes soon becomes hard to track. Teams often fall back on shared static keys for internal services to save time. Those static keys rarely rotate and often end up in plain text files.
Database Proxy (ProxySQL, PgBouncer) + Kong Security Plugins: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native routing solves and what it misses
This native setup works well for north-south web traffic from public users and apps. It handles TLS termination, request rate limits, and basic header checks at high speed. It also gives platform teams one clear entry point for all external web services. Central routing stops teams from exposing every single backend microservice directly to the public internet.
Yet this setup leaves a clear gap for internal engineers and direct database sessions. A web router checks who sends an HTTP call, not what happens inside a session. Once a request passes the route check, the caller gets full access to that endpoint. Also, standard API routing does not govern interactive command sessions or raw database queries. It cannot ask a peer to approve a single risky command in real time. It also does not rewrite sensitive fields like emails or card numbers in query results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between a service and a route?
A service represents your actual backend web app or upstream API server. A route defines the public path and rules that send client traffic to that service.
How do teams update routing rules without downtime?
Teams push declarative state files or call the admin interface on the control plane. The data plane nodes load these new rules in memory without dropping active calls.
Does an API router secure direct engineer sessions to databases?
No, standard API routers focus on web traffic and basic TCP streams for apps. They do not inspect individual SQL queries or mask sensitive data fields in results.