Intro to RBAC in Sensu Go

Last month, we ran a webinar on role-based access control (RBAC) in Sensu Go. In this post, we’ll capture some of the key points from the presentation and show you how RBAC can help you lock down access for increased security and team efficiency.

API keys and what they mean for RBAC

Sensu Go 5.15 introduced API keys: long-lived authentication tokens that make it easier to authenticate with Sensu-adjacent applications. The Sensu backend generates API keys, and you, in turn, provide them to applications that want to interact with the Sensu API. With API keys, you can easily grant or revoke access to external services or automation as needed, helping teams of any size maintain more granular control over what gets access to their monitoring. When used in conjunction with RBAC, you have an even more powerful way to narrowly limit API access.

Here’s how the API key interaction works with sensuctl:

Now, you have a top-level command (sensuctl api-key list, for example, lets you find external services that need to access the API) that lets you easily put the API keys to work. In the example above I show how to use API keys to create Sensu events in an ad-hoc manner, similar to how you might have an external service integrate with Sensu using an output webhook mechanism. I also walk through the basics of how to grant/revoke keys and how to use them in HTTP request headers.

As you can see, API keys are super powerful. And what I demonstrate in the demo above is not actually how you want to use API keys (do as I say, and not as I do) — don’t use them for users with full access to the API. Make sure you apply access control limits so you can narrowly give access to a user, so they only do what you want them to do (so in this example, just access to the events API).

A quick note on access control models

Before we get into RBAC, here’s a quick overview of a few common access control models:

• Discretionary access control (DAC) is focused on resource ownership. It tends to rely on access control lists (ACLs) attached to individual objects to grant permissions to other entities. The DAC model is common in networking and filesystems.
• Mandatory access control (MAC) is an OS-enforced security policy, commonly implemented as filesystem security attributes on filesystem objects (e.g., SELinux).
• Role-based access control (RBAC) is based on defining roles and corresponding privileges. A user can access objects and execute operations only if their roles in the system have the relevant permissions.

Durable business roles with RBAC

For the RBAC model, you focus on centrally managed, durable business roles. These roles define a collection of permissions to perform specific functions relevant to that role. For example, you have an operator role: you want them to be able to create checks, but not create new roles or RoleBindings. An auditor role, for example, might be able to see what checks are in place but they don’t have the capability of creating new ones.

This model is used widely in REST APIs to provide more granular control to REST methods; when you’re doing a job function, you have to hit multiple endpoints in order to get your work done. You roll those all up as a set of rules and cut them up in different ways relevant to your roles. You can also bind users or groups to multiple roles (a user can wear multiple hats in the same system). This enables Sensu to have multi-tenancy and allows different teams inside of an org to design their own access patterns to match operational requirements.

We borrowed heavily from the Kubernetes’ model in terms of resource concepts:

• Roles, which are tied to a namespace and include permissions for namespace-scoped resources.
• RoleBindings, which are also tied to a namespace and are the mappings between users/groups and roles.
• ClusterRoles and ClusterRoleBindings, which include permissions for all namespaced resources and resources not scoped to a namespace (e.g., users). Be careful with these — work with roles and RoleBindings first, since ClusterRoles are used to define admin access (you can easily lock yourself out).

For a deeper dive on RoleBindings, ClusterRoles, and ClusterRoleBindings,check out this post.

Now for a quick demo on building out those access controls using the script from earlier:

Here I set up a role to narrowly grant check execution to a user so I can execute an adhoc check via the Sensu API. I use several Particle.io sensors for some home projects, and interface the Particle.io cloud API with my Sensu-based monitoring using Particle’s event-driven webhooks.

If you want to play around with setting up roles, we recommend setting up a test namespace, after which you integrate the roles you want into a production namespace. Sensu namespaces are a key part of Sensu’s multi-tenancy feature — similar to Kubernetes.

Recapping RBAC practices for inbound webhooks

This is the workflow we recommend for inbound webhooks:

1. Create a role that declares the needed Sensu namespace permissions (e.g., event-submit-only)
2. Create a dedicated user (e.g., particle_io_service)
3. Create a role binding to connect the user with the role
4. Grant the user API key (this is the last step, as you’re actually turning it on and making use of the access you set up)

RBAC resources

Here are a few resources from our documentation, the blog, and our Community Forum on Discourse:

• RBAC reference for everything you ever wanted to know about RBAC in Sensu Go.
• Creating a read-only user, a great guide for getting started with RBAC.
• Using RBAC for self-service monitoring, which piggybacks on the read-only user guide above to give you reusable configs.
• Understanding RBAC in Sensu Go, a blog post from Sensu Engineer Simon Plourde that walks through a brief history of RBAC and how we implemented it in Sensu Go.
• The video recording of our webinar, including the demos above.

We hope this post gets you started on your journey to multi-tenancy and more granular control of your monitoring! Join us on Discourse to share your learnings and ask questions from the community. In the meantime, happy monitoring!