Access Control for the Kubernetes API Server Using KubeGate

KubeGate is a new component we built for access control of the Kubernetes API server: a pass-through proxy that sits on every control-plane node, in front of the API server, acting as a front door you can control and lock down. All traffic reaching the API server runs through it and is logged, including the client's real IP, with no extra setup. KubeGate decrypts nothing.

That API server sits on the public internet. KubeGate guards who can connect to it, and makes sure the audit log shows who actually did.

How does KubeGate work without holding your keys?

KubeGate takes the public API port and forwards the raw TLS straight through to the API server, which listens only on the node's loopback address. Because it never decrypts, the API server still presents its own certificate and authenticates every caller itself, end to end. KubeGate runs as an unprivileged user. It holds no key and can't sign anything, so it can decide who connects but never issue a credential.

By design it can never lock a cluster out. Your nodes and the management plane always get through, so tightening access can't strand the cluster from itself. What you can control is the outside world.

Why can't the API server see the real client IP?

Behind a load balancer, the Kubernetes API server only ever sees the load balancer's own address, so every request in your audit log gets pinned to the same internal hop. That's not something you misconfigured. A load balancer forwards the real client address in a small prefix called the PROXY protocol header, and the API server has no native way to read it. It's a long-standing gap in Kubernetes itself, raised upstream back in 2019.

KubeGate closes it on our side. It reads the real client address from the PROXY header, then a privileged helper on the node writes that address into the audit log. Because the helper sets it locally, on the node, after the connection has already passed the gate, a remote client can't forge it, and you don't configure anything. So your audit log finally names the actual caller instead of the load balancer. The same setup lets the load balancer check each control plane with a real HTTP readiness probe that KubeGate answers, so traffic reaches a node only once its API server is actually serving.

How do you restrict who reaches the API server?

You can limit which client IP ranges reach the API server through the load balancer to a list you trust, and your nodes and the platform keep working through it. It's an allow-list for the public path, layered in front of the authentication the API server already does. The step-by-step is in Restrict API server access.

The allow-list is a control on the network path. It doesn't replace RBAC, which still decides what an admitted caller may do. Once you have the real client IP, you can read it back out of your audit logs.

What are the limits?

KubeGate guards the path that comes in from the internet. A caller already on the node, say a process reaching the API server on its loopback address, doesn't pass through the gate. It gains no extra access, because the API server still authenticates it, but its request shows up in the audit log as coming from the node itself. So the backstop is an alert on API activity that looks like it came from the node's own address.

FAQ

Does KubeGate see or store my API traffic?

No. It forwards raw TLS without decrypting, so it never sees inside a request. The API server remains the thing that authenticates every caller.

Do I have to configure anything to get the real client IP?

No. The real-IP behavior is automatic. The optional part is the trusted-range allow-list, which you set when you want to restrict who reaches the API server.

Can locking down access strand my cluster?

No. Nodes and the management plane always get through by design, so an access rule only ever affects outside callers.

KubeGate decides who reaches the control plane and records the real caller. The other audit signals build on that record.