Create a read-only user with role-based access control
Role-based access control (RBAC) allows you to exercise fine-grained control over how Sensu users interact with Sensu resources. Use RBAC rules to achieve multitenancy so different projects and teams can share a Sensu instance.
Sensu RBAC helps different teams and projects share a Sensu instance. RBAC allows you to manage users and their access to resources based on namespaces, groups, roles, and bindings.
By default, Sensu includes a default
namespace and an admin
user with full permissions to create, modify, and delete resources within Sensu, including RBAC resources like users and roles.
Requirements
This guide requires a running Sensu backend and a sensuctl instance configured to connect to the backend as the admin
user.
Create a read-only user
In this section, you’ll create a user and assign them read-only access to resources within the default
namespace using a role and a role binding.
-
Create a user with the username
alice
and assign them to the groupops
:sensuctl user create alice --password='password' --groups=ops
This command creates the following user:
username: alice groups: - ops disabled: false
{ "username": "alice", "groups": [ "ops" ], "disabled": false }
-
Create a
read-only
role withget
andlist
permissions for all resources (*
) within thedefault
namespace:sensuctl role create read-only --verb=get,list --resource=* --namespace=default
This command creates the following role resource definition:
--- type: Role api_version: core/v2 metadata: name: read-only spec: rules: - resource_names: null resources: - '*' verbs: - get - list
{ "type": "Role", "api_version": "core/v2", "metadata": { "name": "read-only" }, "spec": { "rules": [ { "resource_names": null, "resources": [ "*" ], "verbs": [ "get", "list" ] } ] } }
-
Create an
ops-read-only
role binding to assign theread-only
role to theops
group:sensuctl role-binding create ops-read-only --role=read-only --group=ops
This command creates the following role binding resource definition:
--- type: RoleBinding api_version: core/v2 metadata: name: ops-read-only spec: role_ref: name: read-only type: Role subjects: - name: ops type: Group
{ "type": "RoleBinding", "api_version": "core/v2", "metadata": { "name": "ops-read-only" }, "spec": { "role_ref": { "name": "read-only", "type": "Role" }, "subjects": [ { "name": "ops", "type": "Group" } ] } }
All users in the ops
group now have read-only access to all resources within the default namespace.
You can also use role bindings to tie roles directly to users using the --user
flag.
To manage your RBAC configuration, use the sensuctl user
, sensuctl role
, and sensuctl role-binding
commands.
Create a cluster-wide event-reader user
Suppose you want to create a user with read-only access to events across all namespaces. Because you want this role to have cluster-wide permissions, you’ll need to create a cluster role and a cluster role binding.
-
Create a user with the username
bob
and assign them to the groupops
:sensuctl user create bob --password='password' --groups=ops
This command creates the following user:
username: bob groups: - ops disabled: false
{ "username": "bob", "groups": [ "ops" ], "disabled": false }
-
Create a
global-event-reader
cluster role withget
andlist
permissions forevents
across all namespaces:sensuctl cluster-role create global-event-reader --verb=get,list --resource=events
This command creates the following cluster role resource definition:
--- type: ClusterRole api_version: core/v2 metadata: name: global-event-reader spec: rules: - resource_names: null resources: - events verbs: - get - list
{ "type": "ClusterRole", "api_version": "core/v2", "metadata": { "name": "global-event-reader" }, "spec": { "rules": [ { "resource_names": null, "resources": [ "events" ], "verbs": [ "get", "list" ] } ] } }
-
Create an
ops-event-reader
cluster role binding to assign theglobal-event-reader
role to theops
group:sensuctl cluster-role-binding create ops-event-reader --cluster-role=global-event-reader --group=ops
This command creates the following cluster role binding resource definition:
--- type: ClusterRoleBinding api_version: core/v2 metadata: name: ops-event-reader spec: role_ref: name: global-event-reader type: ClusterRole subjects: - name: ops type: Group
{ "type": "ClusterRoleBinding", "api_version": "core/v2", "metadata": { "name": "ops-event-reader" }, "spec": { "role_ref": { "name": "global-event-reader", "type": "ClusterRole" }, "subjects": [ { "name": "ops", "type": "Group" } ] } }
All users in the ops
group now have read-only access to events across all namespaces.
What’s next
Now that you know how to create a user, a role, and a role binding to assign a role to a user, check out the RBAC reference for in-depth documentation on role-based access control, examples, and information about cluster-wide permissions.
Read about monitoring as code with Sensu and learn how to use SensuFlow to synchronize your monitoring and observability code with your Sensu deployments.