Jef Practice: Reusable RBAC to setup team namespace for self-service monitoring

Sensu Go
1

Here’s a practical example of using RBAC to provide self-service monitoring for distinct teams in your organization using a single Sensu server configuration. The premise is each team will be running its own agents and will need its own check,assets, and handlers… all the things in a self-service manner…without bumping into each other.

Before diving in to this practical example, take a look at this blog post describing how Sensu RBAC works: https://blog.sensu.io/understanding-rbac-in-sensu-go

Here’s a Sensu role / role-binding pattern I like to follow when namespaces for teams.
I keep these handy as a single yaml file…and when I need to apply it to a new team I just do a quick find replace on <<namspace>> in line with sed before sending it to sensuctl create
Here’s a gist link to the file:

Or when integrating with a config/change management system, use this yaml as a template for the cm to use to establish a new namespace resource collection.

Here’s run down of my team namespace pattern.

  1. Create the Sensu namespace
    this is pretty self-explanatory

  2. Create Namespace Roles: Admin,Operator,Viewer

  • The Admin role has full access to all resources in the namespace, including roles and role-bindings.
  • The Operator has full access to most things, except the RBAC resources…so they can’t add or remove access to the namespace resources.
  • The Viewer has read access to everything in the namespace, but can’t make any changes.

  1. Create Role Bindings using Associated Groups for each role:
    Note I’m making role bindings for both sensu defined groups and ldap groups as separate rules.
    I have my LDAP authentication configured to use the ldap: prefix to indicate which groups are defined in ldap, to distinguish them from Sensu defined groups. The ldap integration is a Sensu Enterprise feature, but if you aren’t using Sensu Enterprise, you don’t have to worry about the ldap: version of these role-binding rules, everything will still work with sensu defined users, as long as those users are in one of these groups.

  2. Add users to groups
    For enterprise users, this probably means working with your LDAP or AD server and putting users in the correct groups there. For Sensu OSS users, you can adjust Sensu user definitions and defined groups as neeed. In Sensu, groups are an implied resource, defined only in the scope of users. So as soon as you add your first user to a group, that group effective exists.

The generic config file I provided above takes care of 1-3. You still have to populate the users into the corresponding groups that are associated with the role bindings either in Sensu or in your LDAP/AD server.

1 Like