The cluster was down at 3 a.m., but none of the engineers were there to see it. Access logs told the story: someone without the right auth slipped through a crack in a homegrown proxy. It was the kind of problem that shouldn’t exist—and doesn’t have to—when using an Identity-Aware Proxy with K9S.
K9S is the tool many swear by for Kubernetes management, but by itself, it assumes you’ve already locked down the perimeter. That assumption is dangerous. Direct kubeconfig access and unsecured endpoints open doors you don’t want open. An Identity-Aware Proxy changes the math. It drops an authentication layer right in front of the Kubernetes API, binding access to identity instead of just possession of a file or token.
When you put an Identity-Aware Proxy in front of K9S, you close gaps that RBAC alone can’t solve. This is not just about adding OAuth or SSO. It’s about verifying who is accessing what in real time and using context like device trust, location, or group membership to make the call. The result: every kubectl or K9S action becomes identity-bound and policy-driven, with no exposed credentials sitting on laptops or in forgotten CI jobs.