K9s Show Secrets
To run the k9s show secrets workflow, open the secret resource view in your terminal. Then use the built-in decode action to turn base64 strings into plain text. Many engineering teams use this terminal tool to check cluster state and fix broken apps. They often share one broad admin role so everyone can fix issues fast. When roles are too broad, anyone in the cluster can read every plain text key. How the k9s show secrets workflow operates K9s is a terminal user interface that talks straight
K8s Secrets Management: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To run the k9s show secrets workflow, open the secret resource view in your terminal. Then use the built-in decode action to turn base64 strings into plain text. Many engineering teams use this terminal tool to check cluster state and fix broken apps. They often share one broad admin role so everyone can fix issues fast. When roles are too broad, anyone in the cluster can read every plain text key.
How the k9s show secrets workflow operates
K9s is a terminal user interface that talks straight to your Kubernetes API server. It reads the local kubeconfig file on your machine to log in. When you ask to view secrets, the tool sends a read request to the cluster. The API server checks if your Kubernetes role allows you to list or get secrets. If the role allows it, the server sends back the full secret object.
Kubernetes stores secret values as base64 text rather than strong encryption by default. K9s hides the values on screen at first so people nearby do not read them. When the user triggers the decode action, K9s converts the base64 data into plain text. All of this happens right inside the local terminal client using the same cluster permission. If your local user can get the secret object, your tool can decode it.
What native cluster roles solve and what they miss
Kubernetes role-based access control lets teams limit which namespaces or resources a user can read. You can write a rule that stops junior developers from listing secret objects in production. You can also bind roles to specific groups from your identity provider. This setup works well for static boundaries between teams and separate cluster spaces.
Still, native cluster roles are all-or-nothing once a user logs into a live session. If an engineer needs to check one broken app secret, they need secret read rights. Native roles often grant read rights across the whole namespace at once. The cluster decides who can log in and fetch objects at the start. It does not inspect individual commands or requests in flight to block bulk secret reads.
Static kubeconfig files on laptops also create a long-term risk for security teams. Those local files often hold long-lived keys or broad cluster roles that rarely change. Standard API audit logs record that a user fetched a secret object. Yet they do not give an easy way to approve a single read action first. They also cannot rewrite sensitive fields like emails or card numbers inside returned output.
K8s Secrets Management: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to tighten secret access during live troubleshooting
Start by removing broad cluster-admin roles from daily developer accounts. Give engineers read-only roles that cover pods, logs, and events, but exclude secret objects. Keep secret read permissions inside a separate role reserved for active incidents. This stops casual browsing of keys inside terminal tools during normal daily work.
Next, require short-lived sessions whenever someone needs to inspect a production secret. Instead of keeping static keys on laptops, make engineers log in through your identity provider. Scope each session to the exact namespace and resource type needed for the fix. Review the command history after the incident closes to verify which secrets were read.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Does K9s store decoded secrets on the local disk?
No, K9s decodes the base64 text in memory while you view the terminal screen. Still, your local kubeconfig file still stays on disk with your cluster login keys.
Can Kubernetes RBAC block the decode step inside K9s?
No, the decode step happens locally on your laptop after the API sends the object. If Kubernetes RBAC lets you read the secret, your local tool can decode it.
Why can I list secrets in K9s but not view their contents?
Your cluster role likely allows the list verb but blocks the get verb on secrets. You need the get permission on the secret resource to fetch the actual payload.