From a2e24015ddb9a90cc1b957a76282e93454a5ad6d Mon Sep 17 00:00:00 2001 From: Frank van Lankvelt Date: Wed, 28 May 2025 14:54:03 +0200 Subject: [PATCH 1/6] STAC-22208: document RBAC on Rancher --- SUMMARY.md | 2 +- setup/security/authentication/file.md | 2 +- setup/security/authentication/oidc.md | 47 ++++++ setup/security/rbac/README.md | 26 ++++ setup/security/rbac/rbac_rancher.md | 134 ++++++++++++++++++ .../rbac/role_based_access_control.md | 28 ---- 6 files changed, 209 insertions(+), 30 deletions(-) create mode 100644 setup/security/rbac/rbac_rancher.md delete mode 100644 setup/security/rbac/role_based_access_control.md diff --git a/SUMMARY.md b/SUMMARY.md index b225df7d2..492ba9e1a 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -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) diff --git a/setup/security/authentication/file.md b/setup/security/authentication/file.md index 7768f3d02..3e773fd8d 100644 --- a/setup/security/authentication/file.md +++ b/setup/security/authentication/file.md @@ -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 diff --git a/setup/security/authentication/oidc.md b/setup/security/authentication/oidc.md index 3344f0a74..fac52276e 100644 --- a/setup/security/authentication/oidc.md +++ b/setup/security/authentication/oidc.md @@ -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:///loginCallback?client_name=StsOidcClient" +``` +After creation, Rancher will add a `status` field: +``` +status: + clientID: +``` +This will lead to the creation of a secret with name `` 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: + oidc: + clientId: "" + secret: "" + baseUrl: "" +``` +You can override and extend some of the OIDC config for Rancher with the following fields: +- `discoveryUri` +- `redirectUri` +- `customParams` + +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: diff --git a/setup/security/rbac/README.md b/setup/security/rbac/README.md index 8e608839f..f7fa7a732 100644 --- a/setup/security/rbac/README.md +++ b/setup/security/rbac/README.md @@ -4,3 +4,29 @@ 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. + +## 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) +* [Permissions](rbac_permissions.md) +* [How to set up roles](rbac_roles.md) +* [Scopes](rbac_scopes.md) +* [How to configure authentication](../authentication/) + + diff --git a/setup/security/rbac/rbac_rancher.md b/setup/security/rbac/rbac_rancher.md new file mode 100644 index 000000000..f519906b5 --- /dev/null +++ b/setup/security/rbac/rbac_rancher.md @@ -0,0 +1,134 @@ +--- +description: SUSE Observability Self-hosted +--- + +## Overview + +The SUSE Rancher Prime Observability Extension allows RBAC configuration of users access in SUSE Observability. + +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. + +A standalone installation of SUSE Observability supplies predefined groups that correspond to the below instance roles. + +### Observer role + +The observer role grants a user the permission to read topology, metrics, logs and trace data for a namespace or a cluster. See [rbac_resources](RBAC resources) +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. + +### Instance roles + +There are four roles predefined in SUSE Observability: + +* **Recommended Access** - has recommended permissions for using SUSE Observability. +* **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. This role includes access to all data in an observability instance. +* **Instance Administrator** - has full access to all views and has all permissions. This role includes access to all data in an observability instance. + +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). + diff --git a/setup/security/rbac/role_based_access_control.md b/setup/security/rbac/role_based_access_control.md deleted file mode 100644 index e349f75a8..000000000 --- a/setup/security/rbac/role_based_access_control.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -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. - -## 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? - -A role in SUSE Observability 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). - -## More on RBAC configuration - -* [Permissions](rbac_permissions.md) -* [How to set up roles](rbac_roles.md) -* [Scopes](rbac_scopes.md) -* [How to configure authentication](../authentication/) - From f62f9d09a28c1c22107310e7b1f3c0d248e5cd77 Mon Sep 17 00:00:00 2001 From: Frank van Lankvelt Date: Mon, 2 Jun 2025 08:43:00 +0200 Subject: [PATCH 2/6] STAC-22208: fix links --- setup/security/rbac/rbac_rancher.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/setup/security/rbac/rbac_rancher.md b/setup/security/rbac/rbac_rancher.md index f519906b5..10808275d 100644 --- a/setup/security/rbac/rbac_rancher.md +++ b/setup/security/rbac/rbac_rancher.md @@ -16,8 +16,7 @@ A standalone installation of SUSE Observability supplies predefined groups that ### Observer role -The observer role grants a user the permission to read topology, metrics, logs and trace data for a namespace or a cluster. See [rbac_resources](RBAC resources) -There are three `RoleTemplate`s that grant access to observability data: +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. From 9ffb065c716200474636be9541be4f0cd0eb7095 Mon Sep 17 00:00:00 2001 From: Frank van Lankvelt Date: Mon, 2 Jun 2025 08:54:25 +0200 Subject: [PATCH 3/6] STAC-22208: format table --- setup/security/rbac/rbac_rancher.md | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/setup/security/rbac/rbac_rancher.md b/setup/security/rbac/rbac_rancher.md index 10808275d..38c1d2a6d 100644 --- a/setup/security/rbac/rbac_rancher.md +++ b/setup/security/rbac/rbac_rancher.md @@ -12,8 +12,6 @@ Two kinds of roles are used for accessing SUSE Observability: 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. -A standalone installation of SUSE Observability supplies predefined groups that correspond to the below instance roles. - ### 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: @@ -35,17 +33,22 @@ The permissions assigned to each predefined SUSE Observability role can be found {% 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* | + +| 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* | + +| Resource | Verbs | +| --- | --- | | agents | get | | apitokens | get | | componentactions | execute | @@ -64,11 +67,14 @@ The Troubleshooter role has access to all data available in SUSE Observability a | traces | get | | views | get, create, update, delete | | visualizationsettings | get | + {% endtab %} {% tab title="Administrator" %} The Administrator role has all permissions assigned. -| *Resource* | *Verbs* | + +| Resource | Verbs | +| --- | --- | | agents | get | | apitokens | get | | componentactions | execute | @@ -93,6 +99,7 @@ The Administrator role has all permissions assigned. | traces | get | | views | get, create, update, delete | | visualizationsettings | update | + {% endtab %} @@ -107,7 +114,9 @@ These resources correspond to data collected by the SUSE Observability agent and 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* | + +| 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) | @@ -118,7 +127,6 @@ Apart from these RBAC resources controlling access to observability data, "insta | `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 | @@ -129,5 +137,5 @@ Apart from these RBAC resources controlling access to observability data, "insta | `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). +| `visualizationsettings` | `update` | Change [visualization settings](/use/views/k8s-topology-perspective.md#visualization-settings). | From 3f24058d54ec5a63ab731913567807487cf35563 Mon Sep 17 00:00:00 2001 From: Frank van Lankvelt Date: Mon, 2 Jun 2025 08:59:40 +0200 Subject: [PATCH 4/6] STAC-22208: fix tyop in rancher oidc auth --- setup/security/authentication/oidc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/setup/security/authentication/oidc.md b/setup/security/authentication/oidc.md index fac52276e..0ac22334c 100644 --- a/setup/security/authentication/oidc.md +++ b/setup/security/authentication/oidc.md @@ -48,7 +48,7 @@ To configure Rancher as the OIDC provider for SUSE Observability, the OIDC detai ```yaml stackstate: authentication: - oidc: + rancher: clientId: "" secret: "" baseUrl: "" From 2ca06a512ceeb7cd21aca549dd172fe6c82a59e5 Mon Sep 17 00:00:00 2001 From: Frank van Lankvelt Date: Mon, 2 Jun 2025 09:32:41 +0200 Subject: [PATCH 5/6] STAC-22208: add section on system:authenticated --- setup/security/rbac/rbac_rancher.md | 30 +++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/setup/security/rbac/rbac_rancher.md b/setup/security/rbac/rbac_rancher.md index 38c1d2a6d..b179c785b 100644 --- a/setup/security/rbac/rbac_rancher.md +++ b/setup/security/rbac/rbac_rancher.md @@ -139,3 +139,33 @@ Apart from these RBAC resources controlling access to observability data, "insta | `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" +``` + From 95f4209132f12c73b58e9563ee9501bf7c62f05e Mon Sep 17 00:00:00 2001 From: Frank van Lankvelt Date: Mon, 2 Jun 2025 15:31:55 +0200 Subject: [PATCH 6/6] STAC-22208: make separation between standalone & rancher RBAC clearer --- setup/security/authentication/oidc.md | 8 ++++---- setup/security/rbac/README.md | 8 +++++--- setup/security/rbac/rbac_permissions.md | 4 ++++ setup/security/rbac/rbac_rancher.md | 14 +++++++++----- setup/security/rbac/rbac_roles.md | 2 ++ setup/security/rbac/rbac_scopes.md | 22 +++++++++++++--------- 6 files changed, 37 insertions(+), 21 deletions(-) diff --git a/setup/security/authentication/oidc.md b/setup/security/authentication/oidc.md index 0ac22334c..2f25118d3 100644 --- a/setup/security/authentication/oidc.md +++ b/setup/security/authentication/oidc.md @@ -53,10 +53,10 @@ stackstate: secret: "" baseUrl: "" ``` -You can override and extend some of the OIDC config for Rancher with the following fields: -- `discoveryUri` -- `redirectUri` -- `customParams` +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 diff --git a/setup/security/rbac/README.md b/setup/security/rbac/README.md index f7fa7a732..9e361f8ba 100644 --- a/setup/security/rbac/README.md +++ b/setup/security/rbac/README.md @@ -8,6 +8,10 @@ Access Management helps you manage who has access to the specific topology eleme 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: @@ -24,9 +28,7 @@ This depends a bit on how SUSE Observability is deployed. Both modes of deploym ## More on RBAC configuration * [Rancher RBAC](rbac_rancher.md) -* [Permissions](rbac_permissions.md) -* [How to set up roles](rbac_roles.md) -* [Scopes](rbac_scopes.md) +* [Standalone RBAC](rbac_roles.md) * [How to configure authentication](../authentication/) diff --git a/setup/security/rbac/rbac_permissions.md b/setup/security/rbac/rbac_permissions.md index 0511e835e..23587a644 100644 --- a/setup/security/rbac/rbac_permissions.md +++ b/setup/security/rbac/rbac_permissions.md @@ -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" %} diff --git a/setup/security/rbac/rbac_rancher.md b/setup/security/rbac/rbac_rancher.md index b179c785b..e0054f6cb 100644 --- a/setup/security/rbac/rbac_rancher.md +++ b/setup/security/rbac/rbac_rancher.md @@ -4,7 +4,8 @@ description: SUSE Observability Self-hosted ## Overview -The SUSE Rancher Prime Observability Extension allows RBAC configuration of users access in SUSE Observability. +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. @@ -20,13 +21,16 @@ The observer role grants a user the permission to read topology, metrics, logs a * **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 four roles predefined in SUSE Observability: +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. -* **Recommended Access** - has recommended permissions for using SUSE Observability. -* **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. This role includes access to all data in an observability instance. -* **Instance Administrator** - has full access to all views and has all permissions. This role includes 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) diff --git a/setup/security/rbac/rbac_roles.md b/setup/security/rbac/rbac_roles.md index 3d6503fda..1de4fbba3 100644 --- a/setup/security/rbac/rbac_roles.md +++ b/setup/security/rbac/rbac_roles.md @@ -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: diff --git a/setup/security/rbac/rbac_scopes.md b/setup/security/rbac/rbac_scopes.md index b351285b2..6132c8239 100644 --- a/setup/security/rbac/rbac_scopes.md +++ b/setup/security/rbac/rbac_scopes.md @@ -2,23 +2,27 @@ description: SUSE Observability Self-hosted --- -# Scopes +# Topology Scopes -## How do scopes work? +{% hint style="warning" %} +The topology scopes discussed here only apply to a *Standalone RBAC* deployment. See [Rancher RBAC](rbac_rancher.md) for the available scopes in a *Rancher RBAC* deployment. +{% endhint %} -The scope is an [STQL query](../../../develop/reference/k8sTs-stql_reference.md) that's added as a prefix to every query executed in SUSE Observability. Whenever a user wants to select a view or pass a query in SUSE Observability, this prefix query is executed as a part of the user's query. This limits the results accordingly to match the user's role. +## How do topology scopes work? + +The topology scope is an [STQL query](../../../develop/reference/k8sTs-stql_reference.md) that's added as a prefix to every query executed in SUSE Observability. Whenever a user wants to select a view or pass a query in SUSE Observability, this prefix query is executed as a part of the user's query. This limits the results accordingly to match the user's role. Note: Please note that function calls like `withCauseOf` and `withNeighborsOf` aren't supported as they would not be performant in this context. -If a user belongs to multiple groups, then this user can have multiple scopes, which translates to multiple prefixes. In this situation, the prefix is executed as an OR of all scopes that this user has. +If a user belongs to multiple groups, then this user can have multiple topology scopes, which translates to multiple prefixes. In this situation, the prefix is executed as an OR of all topology scopes that this user has. Users need to log out and authenticate again to SUSE Observability whenever any changes to roles or permissions are made. -## Why scopes? +## Why topology scopes? -Scopes are introduced as a security feature that's mandatory for every subject within SUSE Observability. The predefined SUSE Observability users Administrator, Power User and Guest roles have no scope defined. +Topology scopes are introduced as a security feature that's mandatory for every subject within SUSE Observability. The predefined SUSE Observability users Administrator, Power User and Guest roles have no scope defined. -It's possible to specify a scope as a query wildcard, however, this will result in access to everything and isn't recommended. If there is a need for access without a scope, it's recommended to use one of the [predefined roles](rbac_permissions.md#predefined-roles) instead. +It's possible to specify a topology scope as a query wildcard, however, this will result in access to everything and isn't recommended. If there is a need for access without a topology scope, it's recommended to use one of the [predefined roles](rbac_permissions.md#predefined-roles) instead. ## Examples @@ -34,7 +38,7 @@ The query for this view is the same as for the others, but without any prefix: 'layer = "Infrastructure" AND domain IN ("Customer1", "Customer2")' ``` -### Below user is in a group with configured subject X with the following scope: +### Below user is in a group with configured subject X with the following topology scope: ```text 'domain = "Customer1"' @@ -48,7 +52,7 @@ Query with the prefix for this view is: '(domain = "Customer1") AND (layer = "Infrastructure" AND domain IN ("Customer1", "Customer2"))' ``` -### Another user who is a part of a group with a configured subject Y that has the following scope: +### Another user who is a part of a group with a configured subject Y that has the following topology scope: ```text 'domain = "Customer2"'