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.

  1. Create a user with the username alice and assign them to the group ops:

    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
    }

  2. Create a read-only role with get and list permissions for all resources (*) within the default 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"
            ]
          }
        ]
      }
    }
  3. Create an ops-read-only role binding to assign the read-only role to the ops 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.

  1. Create a user with the username bob and assign them to the group ops:

    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
    }

  2. Create a global-event-reader cluster role with get and list permissions for events 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"
            ]
          }
        ]
      }
    }
  3. Create an ops-event-reader cluster role binding to assign the global-event-reader role to the ops 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.