TLS Route
You set up a tls route by mapping a server name to a backend app. This rule forwards encrypted network packets to your service without reading the payload. Platform teams use this method to expose databases and internal apps over one port. Still, broad network rules often let any user with the right address reach production. How a tls route directs encrypted traffic A tls route works at the transport layer of your network stack. When a client starts a session, it sends an unencrypted server n
TLS 1.3 Configuration: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a tls route by mapping a server name to a backend app. This rule forwards encrypted network packets to your service without reading the payload. Platform teams use this method to expose databases and internal apps over one port. Still, broad network rules often let any user with the right address reach production.
How a tls route directs encrypted traffic
A tls route works at the transport layer of your network stack. When a client starts a session, it sends an unencrypted server name header. The ingress listener reads this server name during the initial handshake phase. It does not decrypt the traffic or hold the private TLS key. Instead, the listener matches the server name against your active routing rules.
Once the listener finds a match, it forwards the raw TCP stream. The backend pod or database receives the encrypted bytes and runs the handshake. Your backend app holds the private key and decrypts the session locally. This setup keeps encryption end to end from the client to the pod. Teams use this pattern for database traffic, message queues, and custom TCP services. Multiple services can share one public IP address and one network port. The server name header tells the network controller where each stream belongs.
What native routing solves and what it misses
Native TLS routing solves port exhaustion and keeps cloud load balancer costs low. You do not need a separate public IP for every internal database. It also keeps certificates inside the backend app when rules require end-to-end encryption. Network admins can manage traffic paths using standard cluster API objects and roles.
Yet a transport route only decides which network packets reach the target pod. Because the stream stays encrypted in transit, the network layer sees only bytes. It cannot tell which engineer logged in or what query they ran. Once a user passes the database login check, they hold full role permissions. A broad database role lets an engineer run a drop table command by mistake. It also lets a script return thousands of raw emails or card numbers. Standard network logs only show that a TCP session opened and closed. They do not record the SQL statements, shell commands, or API calls inside.
TLS 1.3 Configuration: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Why teams pair network routing with session controls
Security teams need more than IP logs and basic port forwarding rules. Audits require clear proof of who ran each command against production data. When an incident happens, teams must check exact queries rather than packet counts. Relying on static database roles leaves sensitive tables exposed during daily debugging work.
Teams also face risks when engineers pull customer data to local laptops. If a query returns phone numbers or national IDs, network routing sends everything. Adding controls at the command level closes this gap without breaking TLS paths. Masking rules can rewrite matched fields like card numbers in query results. Approval workflows can pause risky commands before they hit the backend service. This approach shifts security from simple port checks to fine-grained action checks.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between TLS passthrough and termination?
Passthrough forwards encrypted bytes straight to the backend app using the server name. Termination decrypts traffic at the edge listener before sending it to the pod.
Can a tls route inspect queries or HTTP headers?
No, a tls route only reads the unencrypted server name during the handshake. It cannot see HTTP paths, headers, or database queries inside the encrypted stream.
When should a team use a tls route instead of an HTTP route?
Use a tls route for non-HTTP traffic like databases, queues, or custom TCP apps. Use it when your backend app must handle its own TLS certificates.