Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -172,7 +172,7 @@
* [Service tokens](setup/security/authentication/service_tokens.md)
* [Troubleshooting](setup/security/authentication/troubleshooting.md)
* [RBAC](setup/security/rbac/README.md)
* [Role-based Access Control](setup/security/rbac/role_based_access_control.md)
* [Rancher](setup/security/rbac/rbac_rancher.md)
* [Permissions](setup/security/rbac/rbac_permissions.md)
* [Roles](setup/security/rbac/rbac_roles.md)
* [Scopes](setup/security/rbac/rbac_scopes.md)
Expand Down
2 changes: 1 addition & 1 deletion setup/security/authentication/file.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ description: SUSE Observability Self-hosted

In case no external authentication provider can be used, you can use file based authentication. This will require every SUSE Observability user to be pre-configured in the configuration file. For every change made to a user in the configuration, SUSE Observability will automatically restart after applying the changes with Helm.

SUSE Observability includes a number of default roles, see the example configuration below. The permissions assigned to each default role and instructions on how to create other roles can be found in the [Role based access control (RBAC) documentation](../rbac/role_based_access_control.md).
SUSE Observability includes a number of default roles, see the example configuration below. The permissions assigned to each default role and instructions on how to create other roles can be found in the [Role based access control (RBAC) documentation](../rbac/README.md).

## Set up file based authentication

Expand Down
47 changes: 47 additions & 0 deletions setup/security/authentication/oidc.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,8 +19,55 @@ Before you can configure SUSE Observability to authenticate using OIDC, you need

The result of this configuration should produce a **clientId** and a **secret**. Copy those and keep them around for configuring SUSE Observability. Also write down the **discoveryUri** of the provider. Usually this is either in the same screen or can be found in the documentation.

### Configuring Rancher as OIDC provider

In order for SUSE Observability to authenticate with Rancher, an OIDC Client needs to be created for it. This can be provisioned as a Kubernetes resource in the Rancher "local" cluster:
```
apiVersion: management.cattle.io/v3
kind: OIDCClient
metadata:
name: oidc-observability
spec:
tokenExpirationSeconds: 600
refreshTokenExpirationSeconds: 3600
redirectURIs:
- "https://<suse-observability-url>/loginCallback?client_name=StsOidcClient"
```
After creation, Rancher will add a `status` field:
```
status:
clientID: <oidc-client-id>
```
This will lead to the creation of a secret with name `<oidc-client-id>` in the `cattle-oidc-client-secrets` namespace.

## Configure SUSE Observability for OIDC

### Rancher

To configure Rancher as the OIDC provider for SUSE Observability, the OIDC details need to be added to the authentication values:
```yaml
stackstate:
authentication:
rancher:
clientId: "<oidc-client-id>"
secret: "<oidc-secret>"
baseUrl: "<rancher-url>"
```
You can override and extend the OIDC config for Rancher with the following fields:
* **discoveryUri** - URI that can be used to discover the OIDC provider. Normally also documented or returned when creating the client in the OIDC provider.
* **redirectUri** - Optional \(not in the example\): The URI where the login callback endpoint of SUSE Observability is reachable. Populated by default using the `stackstate.baseUrl`, but can be overridden. This must be a fully qualified URL that points to the `/loginCallback` path.
* **customParameters** - Optional map of key/value pairs that are sent to the OIDC provider as custom request parameters. Some OIDC providers require extra request parameters not sent by default.

If you need to disable TLS verification due to a setup not using verifiable SSL certificates, you can disable SSL checks with some application config (don't use in production):
```yaml
stackstate:
components:
server:
extraEnv:
open:
CONFIG_FORCE_stackstate_misc_sslCertificateChecking: false
```

### Kubernetes

To configure SUSE Observability to use an OIDC authentication provider on Kubernetes, OIDC details and user role mapping needs to be added to the file `authentication.yaml`. For example:
Expand Down
28 changes: 28 additions & 0 deletions setup/security/rbac/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,3 +4,31 @@ description: SUSE Observability Self-hosted

# Role based access control (RBAC)

Access Management helps you manage who has access to the specific topology elements, UI elements, and which APIs they can call.

RBAC is an authorization system that provides fine-grained access management of SUSE Observability resources, a clean and easy way to audit user privileges and to fix identified issues with access rights.

There are two different ways to configure RBAC:
* **Kubernetes RBAC** - Roles and RoleBindings are provisioned on both the cluster running SUSE Observability as well as any monitored cluster. The supported way to do this is by using Rancher.
* **Standalone RBAC** - Configuration is done via the SUSE Observability application itself.

## What can I do with RBAC?

Here are some examples of what you can do with RBAC:

* Allow one user to have access to the development cluster only, another one to both the production and development cluster and a third can access the development cluster and only 1 namespace in the production cluster.
* Give a small group of users an administrator role to setup and configure SUSE Observability. While giving all developers a troubleshooter role to view all topology, metrics, logs and events, but with limited configuration capability.

## What's a role in SUSE Observability?

This depends a bit on how SUSE Observability is deployed. Both modes of deployment support the same capabilities, but there are slight variations in how scoping is applied.
* **In Rancher** - a role is a Kubernetes Role based on a Rancher `RoleTemplate`, see [Rancher RBAC](rbac_rancher.md) for details. Capabilities are modelled as "verbs" on "resources". Scopes can be set to Instance (all data), Cluster or Namespace and will limit access to topology, metrics and traces.
* **Standalone** - a role is a combination of a configured subject and a set of [permissions](rbac_permissions.md). Process of setting up a role in SUSE Observability is described in [How to set up roles](rbac_roles.md). Scopes are defined with an STQL query, but only apply to topology.

## More on RBAC configuration

* [Rancher RBAC](rbac_rancher.md)
* [Standalone RBAC](rbac_roles.md)
* [How to configure authentication](../authentication/)


4 changes: 4 additions & 0 deletions setup/security/rbac/rbac_permissions.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,10 @@ description: SUSE Observability Self-hosted

## Overview

{% hint style="warning" %}
This page only applies to "Standalone RBAC". Details on permissions in "Rancher RBAC" can be found in [Resource details](rbac_rancher.md#resource-details).
{% endhint %}

Permissions in SUSE Observability allow Administrators to manage the actions that each user or user group can perform inside SUSE Observability and the information that will be shown in their SUSE Observability UI. Only the feature set relevant to each user's active role will be presented. The actions, information and pages that a user doesn't have access to are simply not displayed in their SUSE Observability UI.

{% hint style="info" %}
Expand Down
175 changes: 175 additions & 0 deletions setup/security/rbac/rbac_rancher.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,175 @@
---
description: SUSE Observability Self-hosted
---

## 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](rbac_roles.md) in a standalone installation.

Two kinds of roles are used 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.

A number of `RoleTemplate`s are available to achieve this, with common groupings of permissions. Binding these templates to users or groups on a cluster or namespace will trigger roles and role-bindinds to be provisioned on the target cluster. The default templates are described below. Note that 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. This can be used in the "Project Membership" section of the cluster configuration.
* **Cluster Observer** - grants access to all data coming from a Cluster. This template can be used in the "Cluster Membership" section of the cluster configuration.
* **Instance Observer** - grants access to all data in a SUSE Observability instance. This template can be used on the Project that includes SUSE Observability itself.

In order 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, allowing for configuring the system - setting up views, monitors, notitifications etcetera:
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.

The permissions assigned to each predefined SUSE Observability role can be found below. For details of the different permissions and how to manage them using the `sts` CLI, see [Role based access control (RBAC) permissions](/setup/security/rbac/rbac_permissions.md)

{% tabs %}
{% tab title="Recommended Access" %}
Recommended access grants permissions that are not strictly necessary, but that make SUSE Observability a lot more useful.

| Resource | Verbs |
| --- | --- |
| apitokens | get |
| favoritedashboards | create, delete |
| favoriteviews | create, delete |
| stackpacks | get |
| visualizationsettings | update |

{% endtab %}

{% tab title="Troubleshooter" %}
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 |
| apitokens | get |
| componentactions | execute |
| dashboards | get, create, update, delete |
| favoritedashboards | create, delete |
| favoriteviews | create, delete |
| metricbindings | get |
| metrics | get |
| monitors | get, create, update, delete, execute |
| notifications | get, create, update, delete |
| settings | get |
| stackpackconfigurations | get, create, update, delete |
| stackpacks | get |
| systemnotifications | get |
| topology | get |
| traces | get |
| views | get, create, update, delete |
| visualizationsettings | get |

{% endtab %}

{% tab title="Administrator" %}
The Administrator role has all permissions assigned.

| Resource | Verbs |
| --- | --- |
| agents | get |
| apitokens | get |
| componentactions | execute |
| dashboards | get, create, update, delete |
| favoritedashboards | create, delete |
| favoriteviews | create, delete |
| ingestionapikeys | get, create, update, delete |
| metricbindings | get |
| metrics | get |
| monitors | get, create, update, delete, execute |
| notifications | get, create, update, delete |
| permissions | get, create, update, delete |
| restrictedscripts | execute |
| servicetokens | get, create, update, delete |
| settings | get, create, update, delete, unlock |
| stackpackconfigurations | get, create, update, delete |
| stackpacks | get, create |
| syncdata | get, update, delete |
| systemnotifications | get |
| topicmessages | get |
| topology | get |
| traces | get |
| views | get, create, update, delete |
| visualizationsettings | update |

{% endtab %}


### Resource details

These resources correspond 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 can only be read, so the only applicable verb is `get`.

Apart from these RBAC resources controlling access to observability data, "instance" resources define user capabilities for executing and configuring SUSE Observability:

| Resource | Verbs | Description |
| --- | --- | --- |
| `agents` | `get` | List connected agents with the cli `agent list` command |
| `apitokens` | `get` | Access the CLI page. This provides the API key to use for authentication with the SUSE Observability CLI |
| `componentactions` | `execute` | Execute [component actions](/use/views/k8s-topology-perspective.md#actions) |
| `dashboards` | `get`, `create`, `update`, `delete` | View, create, delete and change dashboards |
| `favoritedashboards` | `create`, `delete` | Manage a personal shortlist of dashboards |
| `favoriteviews` | `create`, `delete` | Manage a personal shortlist of views |
| `ingestionapikeys` | `get`, `create`, `delete` | Manage [API keys](/use/security/k8s-ingestion-api-keys.md) for data ingestion |
| `metricbindings` | `get`, `create`, `update`, `delete` | Create, delete and change [metric bindings](/use/metrics/k8s-add-charts.md) |
| `monitors` | `get`, `create`, `update`, `delete` | Create, delete and change [monitors](/use/alerting/k8s-monitors.md) |
| `notifications` | `get`, `create`, `update`, `delete` | Create, delete and change [notifications](/use/alerting/notifications/configure.md) |
| `restrictedscripts` | `execute` | Execute scripts using the HTTP script API in the SUSE Observability UI analytics environment. Also requires `scripts` |
| `scripts` | `execute` | Execute a query in the SUSE Observability UI Analytics environment. The `restrictedscripts` resource is also required to execute scripts using the HTTP script API |
| `servicetokens` | `get`, `create`, `delete` | Create/delete [Service Tokens](/use/security/k8s-service-tokens.md) in SUSE Observability |
| `settings` | `get`, `create`, `update`, `delete`, `unlock` | Export, import, delete, change and unlock settings |
| `stackpackconfigurations` | `create`, `update`, `delete` | Create, delete and change Stackpack conigurations |
| `stackpacks` | `get`, `create` | List and upload Stackpacks |
| `syncdata` | `get`, `delete` | Access SUSE Observability synchronization status and data using the CLI, reset and delete a synchronization |
| `systemnotifications` | `get` | Access the system notifications in the UI |
| `topicmessages` | `get` | Access SUSE Observability Receiver data using the CLI |
| `views` | `get`, `create`, `update`, `delete` | Access, create, delete and change [views](/use/views/k8s-custom-views.md) in the SUSE Observability UI |
| `visualizationsettings` | `update` | Change [visualization settings](/use/views/k8s-topology-perspective.md#visualization-settings). |


### Granting permissions to every authenticated user

Every authenticated user is automatically added to the `system:authenticated` group. So if you want to grant permissions to, say, view metricbindings, this can be achieved with the manifest:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: everyone-gets-to-see-metricbindings
rules:
- apiGroups:
- instance.observability.cattle.io
resources:
- metricbindings
verbs:
- get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: everyone-gets-to-see-metricbindings
roleRef:
kind: Role
name: everyone-gets-to-see-metricbindings
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
name: "system:authenticated"
```

2 changes: 2 additions & 0 deletions setup/security/rbac/rbac_roles.md
Original file line number Diff line number Diff line change
Expand Up @@ -273,6 +273,8 @@ suse-observability \
suse-observability/suse-observability
```

For details on the `topologyScope`, see [RBAC Scopes](rbac_scopes.md).

### Custom roles via the CLI

To set up a new role called `development-troubleshooter`, which will allow the same permissions as the normal troubleshooter role, but only for the `dev-test` cluster, a new subject needs to be created. Further more this subject needs to be assigned the required set of permissions:
Expand Down
Loading