Kubeconfig Proxy
You set up a kubeconfig proxy by adding a routing URL to your local cluster file. This setup sends every Kubernetes API call through an intermediate host before it reaches the cluster. Engineering teams often use this method to reach private clusters inside a virtual network. Still, standard cluster files often hold broad role permissions that stay active all day. If an engineer has a wide role, every command they send runs without extra checks. How a native kubeconfig proxy setup works A loc
Database Proxy (ProxySQL, PgBouncer): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a kubeconfig proxy by adding a routing URL to your local cluster file. This setup sends every Kubernetes API call through an intermediate host before it reaches the cluster. Engineering teams often use this method to reach private clusters inside a virtual network. Still, standard cluster files often hold broad role permissions that stay active all day. If an engineer has a wide role, every command they send runs without extra checks.
How a native kubeconfig proxy setup works
A local Kubernetes file stores cluster addresses, user keys, and active contexts in one place. When an engineer runs a command, the local tool reads this file first. It checks the target cluster entry to find the server address and network settings. If a routing URL is present, the tool sends the traffic to that host first. That host then forwards the network packet to the private Kubernetes API server.
Teams also use the built-in local server command to open a direct channel. This local process reads the user key and opens a tunnel to the cluster. Local apps can then send plain requests to a local port on the laptop. The background process wraps those calls with the user key and sends them out. Once the request reaches the cluster, Kubernetes checks the role bound to that user key. If the role allows the action, the API server runs the request right away.
Why static cluster files create security risks
Storing keys on laptops makes life easy for engineers, but it creates real risks. Many teams hand out long-lived client certificates or static service account tokens for daily work. These keys sit in plain text inside a file on the user hard drive. If a bad actor steals that file, they gain direct entry to the cluster. Revoking a client certificate across many clusters takes a lot of manual work.
Even with Single Sign-On, the local file caches tokens on the machine. Engineers often share the same admin role to fix broken pods during an outage. That shared role grants way more power than they need for daily tasks. It lets anyone read cluster secrets or delete live workloads by mistake. Static files cannot adapt when an engineer switches from routine checks to urgent fixes.
Database Proxy (ProxySQL, PgBouncer): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native routing solves and what it misses
Native network routing solves the basic problem of reaching a hidden API server. It lets teams keep the Kubernetes control plane off the public internet. Engineers do not need to manage complex network routes by hand for each cluster. Combined with role-based rules, the cluster knows which user or group logged in. This setup works well for basic entry control and simple network paths.
Still, this setup only decides who can talk to the API server. It does not inspect what individual commands or pods do in flight. Once a role grants access to a namespace, the user can run any allowed verb. A developer with exec rights can open a shell inside a live database pod. Standard API audit logs record that a shell opened, not what commands ran inside. Also, when a command reads sensitive rows, native tools return raw emails or card numbers. The native file setup cannot mask fields or require peer approval for one risky command.
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 a tunnel and a local API forwarder?
A network tunnel forwards raw traffic from your laptop to a private network. A local API forwarder handles cluster keys and sends signed calls to the API server.
Do local routing settings hide secrets stored in Kubernetes?
No, local routing settings only direct network traffic to the right server address. If your cluster role allows reading secrets, the API returns the full secret data.
Can native cluster files require approval before deleting a pod?
No, native files only pass your user key to the Kubernetes API server. If your role permits pod deletion, the cluster runs the delete command right away.