K9s List Clusters
To run a k9s list clusters view, open the tool and load the context screen. This screen shows every Kubernetes cluster saved in your local kubeconfig file. Teams often share these files to help engineers switch between staging and prod. Still, broad cluster roles in local files create major security risks. One wrong context switch can wipe out live workloads in seconds. How the k9s list clusters workflow operates The terminal tool reads your local Kubernetes config file when it starts up. It
List Clusters: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To run a k9s list clusters view, open the tool and load the context screen. This screen shows every Kubernetes cluster saved in your local kubeconfig file. Teams often share these files to help engineers switch between staging and prod. Still, broad cluster roles in local files create major security risks. One wrong context switch can wipe out live workloads in seconds.
How the k9s list clusters workflow operates
The terminal tool reads your local Kubernetes config file when it starts up. It does not keep its own separate list of clusters or keys. Instead, it pulls the cluster names, user keys, and contexts from your machine. A context links a specific cluster to a user role and namespace.
When you open the context view, the tool displays all available connections. You can pick any listed context and press enter to switch right away. The interface then reloads and queries the new cluster API server. It uses the local token or client certificate tied to that context.
Many teams store multiple cluster entries inside one single config file. Others split their dev, staging, and prod clusters into separate files. The tool merges these files if your system path lists them all. Once loaded, every cluster appears in one flat list inside the terminal.
What native context switching solves and what it misses
Native context switching makes daily work much faster for platform teams. Engineers do not need to type long commands to change active clusters. They can see which cluster is active right at the top screen. This visual cue helps reduce basic mistakes during routine checks.
Still, local config files only decide who can log in to a cluster. They do not check what commands an engineer runs after logging in. To make debugging easy, teams often grant broad admin roles in these files. Those static keys sit on laptops for weeks or months at a time.
List Clusters: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
When a user switches to a prod context, they carry full admin rights. Kubernetes RBAC checks the role, not the intent of a specific action. A user with edit rights can delete pods or read secret values. Native Kubernetes logs only show the shared role name, not the real person.
Why static kubeconfig files create audit gaps
Sharing cluster config files across a team breaks basic audit trails. Multiple engineers often use the same role to check live apps. When a pod crashes or a secret leaks, logs show one generic role. Security teams cannot tell which team member ran the command.
Local files also make it hard to revoke rights when people change teams. Even if you update a role, old tokens may still work for hours. Also, raw secrets stay visible in plain text inside the terminal view. Anyone who can read a namespace can read its phone numbers or emails. Masked fields that rewrite card numbers or national IDs do not exist natively.
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
Where does the terminal tool find my cluster list?
It reads the standard kubeconfig file stored in your local home folder. If you set a path variable for multiple files, it merges them all.
Why is a cluster missing from my context list?
A cluster will not show up if it lacks a matching context entry. Check your config file to ensure the cluster links to a user.
Can I stop users from viewing secrets when they switch clusters?
Native context lists cannot block secret views on their own. You must limit the Kubernetes role or add a control tool in front.