K9s See Secrets
To make k9s see secrets, open the secret resource view in the terminal interface. Then press the decode shortcut key to show the plain text values. Teams often use this quick workflow to check app settings during an outage. They grant broad read roles so engineers can fix broken pods fast. When roles are too wide, any user can read every key in the cluster. This exposes database passwords and API tokens on local machines. How the k9s see secrets workflow works K9s is a terminal tool that talk
K8s Secrets Management: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To make k9s see secrets, open the secret resource view in the terminal interface. Then press the decode shortcut key to show the plain text values. Teams often use this quick workflow to check app settings during an outage. They grant broad read roles so engineers can fix broken pods fast. When roles are too wide, any user can read every key in the cluster. This exposes database passwords and API tokens on local machines.
How the k9s see secrets workflow works
K9s is a terminal tool that talks to the Kubernetes API server. It uses your local cluster config file to log in and run requests. When you ask the tool to list secrets, it sends a read request. Kubernetes checks if your role has permission to get or list secret objects. If the role allows it, the API sends the secret back to your screen.
By default, Kubernetes stores and sends secret data as base64 strings. Base64 is an encoding format, not real encryption. K9s takes those strings and decodes them right on your local computer. You do not need special cluster add-ons to turn base64 back into plain text. Anyone with read permissions on the secret object can view the raw values.
What native cluster roles solve and what they miss
Kubernetes role-based access control lets you limit who can read cluster objects. You can bind a role to a single namespace or specific secret names. This stops developers from reading keys that belong to other teams. It handles basic login checks and blocks unapproved users at the API door.
Still, native roles are all or nothing once a user logs in. If an engineer needs to check one non-sensitive value, they get the whole secret object. They also see database keys, card numbers, or phone numbers stored in that same object. Native roles decide who logs in, not what individual requests return in flight.
Cluster audit logs also miss the full picture during these sessions. The log shows that a user fetched a secret object at a given time. It does not control what happens to the plain text on the user laptop. Teams end up choosing between blocking debug work or giving out too much trust.
K8s Secrets Management: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Why local kubeconfig files create blind spots
Most teams hand out static cluster files or cloud role keys for daily work. Engineers keep these files on their laptops to run terminal tools with ease. Once that file is on a laptop, every tool on that machine shares those rights. A user can view a secret in the terminal and copy it anywhere.
Revoking or narrowing these rights takes time and often breaks daily work. Platform teams rarely strip read roles after an incident ends. Over time, temporary debug roles turn into permanent wide permissions across all namespaces. To fix this, teams need controls that inspect requests and mask fields like emails in results.
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
Why are Kubernetes secrets shown in base64 by default?
Kubernetes uses base64 so binary data can travel safely inside text config files. It is not a security feature, and any tool can decode it in seconds.
Can I allow a user to see only one key inside a secret?
No, native Kubernetes roles work at the whole object level, not the key level. If a user can read the secret, they can read every key inside it.
Does K9s store decoded secrets on my local disk?
The tool decodes values in memory to show them on your terminal screen. Still, any user can still copy the text from the screen into a local file.