All posts

Separation of Duties in K9S

K9S is a fast terminal UI for managing Kubernetes clusters. It gives real-time access to resources, pods, logs, and events. With great access comes great risk. Without clear Separation of Duties, any operator can deploy, delete, or modify anything—across all namespaces—without peer review or audit trails. Separation of Duties in a K9S workflow means defining who can do what, and ensuring those permissions are enforced at the Kubernetes RBAC level. K9S itself is a client. It respects whatever Ku

Free White Paper

DPoP (Demonstration of Proof-of-Possession) + Just-in-Time Access: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

K9S is a fast terminal UI for managing Kubernetes clusters. It gives real-time access to resources, pods, logs, and events. With great access comes great risk. Without clear Separation of Duties, any operator can deploy, delete, or modify anything—across all namespaces—without peer review or audit trails.

Separation of Duties in a K9S workflow means defining who can do what, and ensuring those permissions are enforced at the Kubernetes RBAC level. K9S itself is a client. It respects whatever Kubernetes lets the connected user account do. This makes RBAC configuration the foundation of secure K9S usage. You assign service accounts, bind them to roles or cluster roles, and grant the least privilege needed for the job. Developers can view logs, troubleshoot pods, and restart services in their own namespace, while admins handle cluster-wide changes and sensitive deployments.

The principle is simple: no single person should have the power to move code from dev to prod, deploy critical images, and approve their own changes. In Kubernetes terms, this means separating roles like “view,” “edit,” and “admin” to prevent privilege creep. K9S reads these rules directly—if the account can’t do it in Kubernetes, it can’t do it in K9S.

Continue reading? Get the full guide.

DPoP (Demonstration of Proof-of-Possession) + Just-in-Time Access: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

To implement Separation of Duties effectively:

  • Create dedicated service accounts for each team function.
  • Define Kubernetes Roles or ClusterRoles with the minimum required verbs and resources.
  • Use RoleBindings or ClusterRoleBindings to attach accounts to roles.
  • Verify limits through K9S by logging in as each account and testing the boundaries.
  • Audit role bindings regularly to ensure no silent privilege escalation.

By controlling what each K9S session can access, you enforce operational safety and compliance, reduce human error, and keep the blast radius small when incidents occur.

This is not theory. Misconfigured access in K9S will bypass your intended guardrails and give the wrong hands the right commands. The fix is precise RBAC design tied to Separation of Duties from day one.

See how RBAC-driven Separation of Duties works with a real K9S setup. Try it with hoop.dev and get it running in minutes.

Get started

See hoop.dev in action

One gateway for every database, container, and AI agent. Deploy in minutes.

Get a demoMore posts