Documentation survey

Rancher RBAC

Overview

The SUSE Rancher Prime Observability Extension uses Kubernetes RBAC to grant access to Rancher users in SUSE Observability. If you do not use Rancher, look at How to set up roles in a standalone installation.

for Rancher RBAC to function, authentication for SUSE Observability must be configured with the Rancher OIDC Provider.

You can use two kinds of roles for accessing SUSE Observability: * A scope role (Observer) grants access to data - either all data in a SUSE Observability instance, data coming from a cluster, or just the data for a namespace. This role is provisioned in a cluster to be observed. * An instance role grants permissions to access or modify functionality of SUSE Observability itself. These roles grant access to all data in SUSE Observability.

Several `RoleTemplate`s are available to achieve this, with common groupings of permissions. Binding these templates to users or groups on a cluster or namespace triggers roles and role-bindings for provisioning on the target cluster. A description of the default templates is below. It is possible to define your own combinations of permissions in a custom RoleTemplate.

Observer role

The observer role grants a user the permission to read topology, metrics, logs and trace data for a namespace or a cluster. There are three `RoleTemplate`s that grant access to observability data:

  • Observer - grants access to data coming from namespaces in a Project. You can use this in the "Project Membership" section of the cluster configuration.

  • Cluster Observer - grants access to all data coming from a Cluster. You can use this template in the "Cluster Membership" section of the cluster configuration.

  • Instance Observer - grants access to all data in a SUSE Observability instance. You can use this template on the Project that includes SUSE Observability itself.

To use these observer roles, it is recommended that the following role is granted on the Project running SUSE Observability itself: * Recommended Access - has recommended permissions for using SUSE Observability.

Instance roles

There are two roles predefined in SUSE Observability, for configuring the system. This includes setting up views, monitors, notifications and so on. As these concern "global" settings of SUSE Observability, these roles include access to all data in an observability instance.

  • Instance Troubleshooter - has all permissions required to use SUSE Observability for troubleshooting, including the ability to enable/disable monitors, create custom views and use the Cli.

  • Instance Administrator - has full access to all views and has all permissions.

You can find the permissions assigned to each predefined SUSE Observability role below. For details of the different permissions and how to manage them using the sts CLI, see Role based access control (RBAC) permissions

  • Recommended Access

  • Troubleshooter

  • Administrator

Recommended access grants permissions that are not strictly necessary, but that make SUSE Observability a lot more useful.

Resource Verbs

api-tokens

get

favorite-dashboards

create, delete

favorite-views

create, delete

stackpacks

get

visualization-settings

update

The Troubleshooter role has access to all data available in SUSE Observability and the ability to create views and enable/disable monitors.

Resource Verbs

agents

get

api-tokens

get

component-actions

execute

dashboards

get, create, update, delete

favorite-dashboards

create, delete

favorite-views

create, delete

metric-bindings

get

metrics

get

monitors

get, create, update, delete, execute

notifications

get, create, update, delete

settings

get

stackpack-configurations

get, create, update, delete

stackpacks

get

system-notifications

get

topology

get

traces

get

views

get, create, update, delete

visualization-settings

get

The Administrator role has all permissions assigned.

Resource Verbs

agents

get

api-tokens

get

component-actions

execute

dashboards

get, create, update, delete

favorite-dashboards

create, delete

favorite-views

create, delete

ingestion-api-keys

get, create, update, delete

metric-bindings

get

metrics

get

monitors

get, create, update, delete, execute

notifications

get, create, update, delete

permissions

get, create, update, delete

restricted-scripts

execute

service-tokens

get, create, update, delete

settings

get, create, update, delete, unlock

stackpack-configurations

get, create, update, delete

stackpacks

get, create

sync-data

get, update, delete

system-notifications

get

topic-messages

get

topology

get

traces

get

views

get, create, update, delete

visualization-settings

update

Resource details

These resources correspond to those of RBAC Permissions. In particular scoped permissions apply to data collected by the SUSE Observability agent and access should typically be limited on a cluster or a namespace level. The following resources are available in the scope.observability.cattle.io API Group:

  • topology - components (deployments, pods, etcetera) from the cluster or namespace

  • traces - spans from the cluster or namespace

  • metrics - metric data originating from the cluster or namespace

These resources are read only, so the only applicable verb is get.

Other permissions, those that are not scoped, define user capabilities and access to parts of SUSE Observability. These "system permissions" allow, for example, executing queries or scripts and configuring SUSE Observability. Those are collected from the instance.observability.cattle.io API Group.

Custom roles

To grant additional permissions beyond Recommended Access, create a custom Project RoleTemplate in Rancher, inheriting from "SUSE Observability Instance Recommended Access". Then, for example, to grant the rights to view monitors and metric charts, add rules with:

  • Verb: get

  • Resource: metricbindings and monitors

  • ApiGroup: instance.observability.cattle.io

Custom RoleTemplate for richer access

You can specify any resource and verb combination defined in the RBAC Permissions. Note that the dashes (-) are dropped from resource names, so the permission get-metric-bindings becomes the Kubernetes RBAC resource metricbindings with the verb get.