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..2f25118d3 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: + rancher: + clientId: "" + secret: "" + baseUrl: "" +``` +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: diff --git a/setup/security/rbac/README.md b/setup/security/rbac/README.md index 8e608839f..9e361f8ba 100644 --- a/setup/security/rbac/README.md +++ b/setup/security/rbac/README.md @@ -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/) + + 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 new file mode 100644 index 000000000..e0054f6cb --- /dev/null +++ b/setup/security/rbac/rbac_rancher.md @@ -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" +``` + 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"' 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/) -