The cluster was alive with traffic. Pods spun up and down in seconds, services shifted, permissions tightened and loosened. You are in the middle of it, running K9s, but one fact hits hard—without Role-Based Access Control (RBAC), this view can become a security hole.
K9s Role-Based Access Control (RBAC) is not an optional feature. It is the line between operational clarity and uncontrolled access. RBAC works by binding Kubernetes roles and cluster roles to specific service accounts. K9s respects Kubernetes permissions exactly. If an account has read-only access to a namespace, K9s will only show what the role allows. If the role has pod delete permissions, K9s will let that action happen.
To configure K9s RBAC, start in Kubernetes.
- Create a
RoleorClusterRolethat defines allowed API actions—get,list,watch,create,delete. - Bind the role to a service account using a
RoleBindingorClusterRoleBinding. - Generate a kubeconfig pointing to that service account credentials.
- Open K9s with that kubeconfig.
K9s will use the exact restrictions set in Kubernetes. This ensures that operators cannot bypass RBAC rules in the tool. Logs, exec shells, and resource edits all require explicit permissions in the RBAC policy.