K9s Readonly
You enable k9s readonly mode through startup settings or a local settings file. This mode turns off delete, edit, and shell actions inside the terminal view. Engineering teams use this setup to look at live pods without breaking production apps. Still, local client settings alone do not change the underlying cluster permissions. If an engineer holds broad cluster roles, they can still run write commands outside the tool. How k9s readonly mode works in practice The terminal tool reads your loc
Readonly: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You enable k9s readonly mode through startup settings or a local settings file. This mode turns off delete, edit, and shell actions inside the terminal view. Engineering teams use this setup to look at live pods without breaking production apps. Still, local client settings alone do not change the underlying cluster permissions. If an engineer holds broad cluster roles, they can still run write commands outside the tool.
How k9s readonly mode works in practice
The terminal tool reads your local cluster credentials to talk to the Kubernetes API. When you turn on the read-only setting, the interface hides change actions from your keyboard menu. You can still view pod logs, check resource usage, and read deployment statuses. If you hit the key to delete a pod, the tool blocks the action right away. You can set this rule for one session or save it in your main settings file. Teams also set this rule per cluster context so production stays safe while test clusters allow edits.
This client lock acts as a helpful guardrail against wrong keystrokes during an outage. Under stress, an operator might press the wrong shortcut while paging through failing pods. The read-only view stops that single keystroke from taking down a live service. Still, the setting lives on the user laptop and depends on the user keeping it turned on.
Combining client settings with Kubernetes role rules
True read-only control requires server-side rules that match your local terminal settings. Kubernetes uses Role-Based Access Control to decide what API calls a user can make. When you bind a user to a view-only cluster role, the API server blocks all write calls. Even if someone turns off their local k9s readonly setting, the cluster rejects any edit or delete request.
Pairing server roles with client settings gives your team a much smoother workflow. If you only restrict the server role, the terminal interface still shows edit and delete keys. When the user presses one, the action fails with an ugly API permission error. When you enable the local read-only mode too, the interface matches the actual cluster role. The user sees only the actions that the cluster will allow them to run.
Readonly: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native settings solve and where gaps remain
Native client settings and cluster roles solve the problem of accidental changes during routine checks. They let developers inspect pod health and read event streams without risking uptime. Still, static roles decide who logs in, not what specific requests do in flight.
A view role often grants read permissions across an entire namespace or cluster. That role might let a user read secret objects or view sensitive customer data inside pod logs. On the other hand, on-call responders sometimes need to delete one stuck pod or run one diagnostic command. Giving them a broad write role for that single task opens the whole cluster to risk. Native roles also struggle to mask sensitive data like emails or card numbers inside log streams. Teams end up choosing between roles that are too narrow to fix issues or too wide to stay safe.
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
Does k9s readonly mode block kubectl commands?
No, the setting only changes what you can do inside the terminal interface itself. A user can still open a new shell window and run standard command-line changes if their cluster role allows it.
Can users still view Kubernetes secrets in read-only mode?
If the underlying Kubernetes role allows reading secret objects, the tool will display them. You must update your cluster role rules on the server if you want to block secret viewing.
Can I set read-only mode for just one cluster context?
Yes, the tool lets you save specific settings for each individual cluster context on your machine. You can lock down your production context while keeping full edit actions turned on for local test clusters.