Visualizing Kubernetes RBAC with Relationship Graphs

In v0.2 of Kubernetes Insights we added relationship graphs that work with other dashboard elements (infocards, charts, tables) to help you visualize the connections among clusters, jobs, namespaces, nodes, pods, roles, and more. Now, in v0.4, you'll find a new set of dashboards that explore role-based access control (RBAC) in Kubernetes. Again, relationship graphs play a key role. Here's the Who can read secrets? dashboard.

It answers the question in two complementary ways. The Secrets RBAC Analysis table shows the principals (of types ServiceAccount, Group, and User) that can read secrets, along with their role bindings and roles; it also enables you to export this data. The Who can read secrets? graph reveals structure implicit in the data. We can see at a glance that system:masters (a group) and system:storageversionmigrator (a user) converge on the cluster role cluster-admin which can apply all verbs to all resources. kubescape-sa (a service account) has permission to read secrets by way of the describe verb. ks-sa-roles can do the same, but also has an alternate path to the same permission.

Who can read secrets? is one of a set of dashboards that answer similar kinds of questions.

You'll notice that one of these is not like the others. Kubernetes RBAC Explorer is an all-purpose dashboard that enables you to choose any verb (or set of verbs) and resource (or set of resources). So, for example, we haven't (yet) made a Who can update certificates? dashboard, but you can use the RBAC Explorer to answer that question by selecting the verb update and the resource certificates.

Here too we see different paths to the same net effective permission. In this case, expanding the verb selection to update,delete would bring another service account (namespace-controller) into the picture, by way of another cluster role called system:controller:namespace-controller.

Although we're using Kubernetes ourselves to run Steampipe Cloud, we're well aware that some of you in the Steampipe community have deeper Kube experience than we do. So we've provided the initial prebuilt Who can? dashboards to show what's possible, so you can in turn show us what other kinds of RBAC questions you want to ask and answer.

The code for a dashboard like Who can read secrets? is straightforward boilerplate: 70 lines of easy-to-modify code. If you don't need to materialize standalone Who can? dashboards in this way, though, you could use Markdown to display links parameterized by verb and resource.

table {
  width = 6
  sql = <<EOQ
    with data(name, link) as (
      values
        ('Who can delete events?','http://localhost:9194/kubernetes_insights.dashboard.rbac_explorer?input.cluster_context=cluster-1&input.verb=*%2Cdelete&input.resource=events'),
        ('Who can describe secrets?','http://localhost:9194/kubernetes_insights.dashboard.rbac_explorer?input.cluster_context=cluster-1&input.verb=*%2Cdescribe&input.resource=secrets'),
        ('Who can escalate privileges via node/proxy?','http://localhost:9194/kubernetes_insights.dashboard.rbac_explorer?input.cluster_context=cluster-1&input.verb=*%2Ccreate,*&input.resource=nodes/proxy'),
        ('Who can delete pods?','http://localhost:9194/kubernetes_insights.dashboard.rbac_explorer?input.cluster_context=cluster-1&input.verb=*%2Cdeletecollection&input.resource=pods'),
        ('Who can update certificates?','http://localhost:9194/kubernetes_insights.dashboard.rbac_explorer?input.cluster_context=cluster-1&input.verb=*%2Cupdate&input.resource=certificates')          
    )
    select * from data
  EOQ
}

In either case there's no need to write SQL to define nodes, edges, and tables. The framework we provide offers low-code and no-code ways to create dashboards that answer these kinds of questions. And as with all Steampipe dashboards you can share these, or snapshot them, or schedule them to run periodically and notify collaborators.

What's next for Kubernetes RBAC in Steampipe? That's up to you! We hope you'll use this new tool to ask and answer the questions that matter most in your environment, then share your ideas with the Steampipe community.