diff --git a/docs/next/modules/en/images/rancher-custom-role.png b/docs/next/modules/en/images/rancher-custom-role.png new file mode 100644 index 00000000..dc67181a Binary files /dev/null and b/docs/next/modules/en/images/rancher-custom-role.png differ diff --git a/docs/next/modules/en/nav.adoc b/docs/next/modules/en/nav.adoc index 254d31f8..9c3de090 100644 --- a/docs/next/modules/en/nav.adoc +++ b/docs/next/modules/en/nav.adoc @@ -155,9 +155,9 @@ **** xref:setup/security/authentication/service_tokens.adoc[Service tokens] **** xref:setup/security/authentication/troubleshooting.adoc[Troubleshooting] *** xref:setup/security/rbac/README.adoc[RBAC] -**** xref:setup/security/rbac/role_based_access_control.adoc[Role-based Access Control] **** xref:setup/security/rbac/rbac_permissions.adoc[Permissions] **** xref:setup/security/rbac/rbac_roles.adoc[Roles] +**** xref:setup/security/rbac/rbac_rancher.adoc[Rancher] **** xref:setup/security/rbac/rbac_scopes.adoc[Scopes] *** xref:setup/security/self-signed-certificates.adoc[Self-signed certificates] *** xref:setup/security/external-secrets.adoc[External secrets] diff --git a/docs/next/modules/en/pages/k8s-quick-start-guide.adoc b/docs/next/modules/en/pages/k8s-quick-start-guide.adoc index 643648ea..d9dc5bd4 100644 --- a/docs/next/modules/en/pages/k8s-quick-start-guide.adoc +++ b/docs/next/modules/en/pages/k8s-quick-start-guide.adoc @@ -79,7 +79,7 @@ To get data from a Kubernetes cluster into SUSE Observability, follow the steps helm repo update ---- -. In the SUSE Observability UI, open the main menu by clicking in the top left of the screen and go to `StackPacks` > `Integrations` > `Kubernetes`. +. In the SUSE Observability UI, open the main menu by clicking in the top left of the screen and go to `StackPacks` > `Kubernetes`. . Install a new instance of the Kubernetes StackPack: ** Specify a *Kubernetes Cluster Name* *** This name will be used to identify the cluster in SUSE Observability diff --git a/docs/next/modules/en/pages/k8s-suse-rancher-prime.adoc b/docs/next/modules/en/pages/k8s-suse-rancher-prime.adoc index 0db09160..08ce3a4e 100644 --- a/docs/next/modules/en/pages/k8s-suse-rancher-prime.adoc +++ b/docs/next/modules/en/pages/k8s-suse-rancher-prime.adoc @@ -234,7 +234,6 @@ helm template \ suse-observability/suse-observability-values --output-dir $VALUES_DIR ---- - The `baseUrl` must be the URL via which SUSE Observability will be accessible to Rancher, users, and the SUSE Observability agent. The URL must include the scheme, for example `+https://observability.internal.mycompany.com+`. See also <<_accessing_suse_observability,accessing SUSE Observability>>. The `sizing.profile` should be one of trial, 10-nonha, 20-nonha, 50-nonha, 100-nonha, 150-ha, 250-ha, 500-ha. Based on this profiles the `sizing_values.yaml` file is generated containing default sizes for the SUSE Observability resources and configuration to be deployed on an Ha or NonHa mode. E.g. 10-nonha will produce a `sizing_values.yaml` meant to deploy a NonHa SUSE Observability instance to observe a 10 node cluster in a Non High Available mode. Currently moving from a nonha to an ha environment is not possible, so if you expect that your environment willrequire to observe around 150 nodes then better to go with ha immediately. @@ -265,6 +264,27 @@ The files can be regenerated independently using the switches `basicConfig.gener The SUSE Observability Values chart generates affinity configurations you can use with the main SUSE Observability chart to control pod scheduling behavior. Refer to xref:/setup/install-stackstate/kubernetes_openshift/affinity.adoc[Configure Kubernetes Affinities]) for more information. ==== +. Configure SUSE Observability to use Rancher as an OIDC provider. + + Generate the `oidc_values.yaml`. This guide assumes that you save it in the `$VALUES_DIR` + ++ +.$VALUES_DIR/oidc_values.yaml +[,yaml] +---- +stackstate: + authentication: + rancher: + clientId: "" + secret: "" + baseUrl: "" +---- ++ +[NOTE] +==== +This step is required if you are planning to use the Rancher RBAC to scope visibility into the downstream clusters. +For a more detailed explanation on how to configure SUSE Observability to use Rancher as an OIDC provider, see xref:/setup/security/authentication/oidc.adoc#_rancher[Configure SUSE Observability for using Rancher as an OIDC provider]. +==== . Deploy the SUSE Observability helm chart with the generated values: @@ -277,6 +297,7 @@ helm upgrade --install \ --values $VALUES_DIR/suse-observability-values/templates/baseConfig_values.yaml \ --values $VALUES_DIR/suse-observability-values/templates/sizing_values.yaml \ --values $VALUES_DIR/suse-observability-values/templates/affinity_values.yaml \ + --values $VALUES_DIR/oidc_values.yaml \ suse-observability \ suse-observability/suse-observability ---- diff --git a/docs/next/modules/en/pages/setup/otel/getting-started/getting-started-k8s-operator.adoc b/docs/next/modules/en/pages/setup/otel/getting-started/getting-started-k8s-operator.adoc index f007460f..0590ba30 100644 --- a/docs/next/modules/en/pages/setup/otel/getting-started/getting-started-k8s-operator.adoc +++ b/docs/next/modules/en/pages/setup/otel/getting-started/getting-started-k8s-operator.adoc @@ -17,16 +17,25 @@ The Open Telemetry operator offers some extra features over the normal Kubernete * It can auto-instrument your application pods for supported languages (Java, .NET, Python, Golang, Node.js), without having to modify the applications or docker images at all * It can be dropped in as a replacement for the Prometheus operator and start scraping Prometheus exporter endpoints based on service and pod monitors -=== Create the namespace and a secret for the API key +=== Create a Service Token -We'll install in the `open-telemetry` namespace and use the receiver API key generated during installation (see xref:/use/security/k8s-ingestion-api-keys.adoc#_api_keys[here] where to find it): +There are two ways to create a service token: + +* **SUSE Observability UI** - open the main menu by clicking in the top left of the screen and go to `StackPacks` > `Open Telemetry`. If you haven't done so before, click the `INSTALL` button. Click the `CREATE NEW SERVICE TOKEN` button and copy the value onto your clipboard. +* **SUSE Observability CLI** - see xref:/use/security/k8s-service-tokens.adoc#_manage_service_tokens[Manage service tokens] + +The service token value must be used where the instructions below mention ``. + +=== Create the namespace and a secret for the service token + +We'll install in the `open-telemetry` namespace and use the service token: [,bash] ---- kubectl create namespace open-telemetry kubectl create secret generic open-telemetry-collector \ --namespace open-telemetry \ - --from-literal=API_KEY='' + --from-literal=API_KEY='' ---- === Configure & Install the operator @@ -315,7 +324,7 @@ The operator, the `OpenTelemetryCollector`, and the `Instrumentation` custom res == More info -* xref:/use/security/k8s-ingestion-api-keys.adoc[API keys] +* xref:/use/security/k8s-service-tokens.adoc[Service tokens] * xref:/setup/otel/otlp-apis.adoc[Open Telemetry API] * xref:/setup/otel/collector.adoc[Customizing Open Telemetry Collector configuration] * xref:/setup/otel/instrumentation/README.adoc[Open Telemetry SDKs] diff --git a/docs/next/modules/en/pages/setup/otel/getting-started/getting-started-k8s.adoc b/docs/next/modules/en/pages/setup/otel/getting-started/getting-started-k8s.adoc index d82de7a6..d96f7f7a 100644 --- a/docs/next/modules/en/pages/setup/otel/getting-started/getting-started-k8s.adoc +++ b/docs/next/modules/en/pages/setup/otel/getting-started/getting-started-k8s.adoc @@ -26,16 +26,25 @@ First we'll install the OTel (Open Telemetry) collector in cluster A. We configu Next to that it will also retry sending data when there are connection problems. -=== Create the namespace and a secret for the API key +=== Create a Service Token -We'll install in the `open-telemetry` namespace and use the receiver API key generated during installation (see xref:/use/security/k8s-ingestion-api-keys.adoc#_api_keys[here] where to find it): +There are two ways to create a service token: + +* **SUSE Observability UI** - open the main menu by clicking in the top left of the screen and go to `StackPacks` > `Open Telemetry`. If you haven't done so before, click the `INSTALL` button. Click the `CREATE NEW SERVICE TOKEN` button and copy the value onto your clipboard. +* **SUSE Observability CLI** - see xref:/use/security/k8s-service-tokens.adoc#_manage_service_tokens[Manage service tokens] + +The service token value must be used where the instructions below mention ``. + +=== Create the namespace and a secret for the service token + +We'll install in the `open-telemetry` namespace and use the service token: [,bash] ---- kubectl create namespace open-telemetry kubectl create secret generic open-telemetry-collector \ --namespace open-telemetry \ - --from-literal=API_KEY='' + --from-literal=API_KEY='' ---- === Configure and install the collector @@ -173,7 +182,7 @@ You can add new charts to components, for example the service or service instanc == More info -* xref:/use/security/k8s-ingestion-api-keys.adoc[API keys] +* xref:/use/security/k8s-service-tokens.adoc[Service tokens] * xref:/setup/otel/otlp-apis.adoc[Open Telemetry API] * xref:/setup/otel/collector.adoc[Customizing Open Telemetry Collector configuration] * xref:/setup/otel/instrumentation/README.adoc[Open Telemetry SDKs] diff --git a/docs/next/modules/en/pages/setup/otel/getting-started/getting-started-lambda.adoc b/docs/next/modules/en/pages/setup/otel/getting-started/getting-started-lambda.adoc index 999897ab..aedc90a5 100644 --- a/docs/next/modules/en/pages/setup/otel/getting-started/getting-started-lambda.adoc +++ b/docs/next/modules/en/pages/setup/otel/getting-started/getting-started-lambda.adoc @@ -19,16 +19,25 @@ For a production setup it is strongly recommended to install the collector, sinc First we'll install the OTel (Open Telemetry) collector, in this example we use a Kubernetes cluster to run it close to the Lambda functions. A similar setup can be made using a collector installed on a virtual machine instead. The configuration used here only acts as a secure proxy to offload data quickly from the Lambda functions and runs within trusted network infrastructure. -=== Create the namespace and a secret for the API key +=== Create a Service Token -We'll install in the `open-telemetry` namespace and use the receiver API key generated during installation (see xref:/use/security/k8s-ingestion-api-keys.adoc#_api_keys[here] where to find it): +There are two ways to create a service token: + +* **SUSE Observability UI** - open the main menu by clicking in the top left of the screen and go to `StackPacks` > `Open Telemetry`. If you haven't done so before, click the `INSTALL` button. Click the `CREATE NEW SERVICE TOKEN` button and copy the value onto your clipboard. +* **SUSE Observability CLI** - see xref:/use/security/k8s-service-tokens.adoc#_manage_service_tokens[Manage service tokens] + +The service token value must be used where the instructions below mention ``. + +=== Create the namespace and a secret for the service token + +We'll install in the `open-telemetry` namespace and use the service token: [,bash] ---- kubectl create namespace open-telemetry kubectl create secret generic open-telemetry-collector \ --namespace open-telemetry \ - --from-literal=API_KEY='' + --from-literal=API_KEY='' ---- === Configure and install the collector @@ -161,7 +170,7 @@ You can add new charts to components, for example the service or service instanc == More info -* xref:/use/security/k8s-ingestion-api-keys.adoc[API keys] +* xref:/use/security/k8s-service-tokens.adoc[Service tokens] * xref:/setup/otel/otlp-apis.adoc[Open Telemetry API] * xref:/setup/otel/collector.adoc[Customizing Open Telemetry Collector configuration] * xref:/setup/otel/instrumentation/README.adoc[Open Telemetry SDKs] diff --git a/docs/next/modules/en/pages/setup/otel/getting-started/getting-started-linux.adoc b/docs/next/modules/en/pages/setup/otel/getting-started/getting-started-linux.adoc index 30ece950..9c708db8 100644 --- a/docs/next/modules/en/pages/setup/otel/getting-started/getting-started-linux.adoc +++ b/docs/next/modules/en/pages/setup/otel/getting-started/getting-started-linux.adoc @@ -26,7 +26,14 @@ First we'll install the collector. We configure it to: Next to that it will also retry sending data when there are a connection problems. -=== Configure and install the collector +=== Create a Service Token + +There are two ways to create a service token: + +* **SUSE Observability UI** - open the main menu by clicking in the top left of the screen and go to `StackPacks` > `Open Telemetry`. If you haven't done so before, click the `INSTALL` button. Click the `CREATE NEW SERVICE TOKEN` button and copy the value onto your clipboard. +* **SUSE Observability CLI** - see xref:/use/security/k8s-service-tokens.adoc#_manage_service_tokens[Manage service tokens] + +The service token value must be used where the instructions below mention ``. === Install and configure the collector @@ -82,7 +89,7 @@ sudo rpm -iv1 otelcol-contrib_0.123.1_linux_arm64.rpm For other installation options use the https://opentelemetry.io/docs/collector/installation/#_linux[Open Telemetry instructions]. -After installation modify the collector configuration by editing `/etc/otelcol-contrib/config.yaml`. Change the file such that it looks like the `config.yaml` example here, replace `` with your OTLP endpoint (see xref:/setup/otel/otlp-apis.adoc[OTLP API] for your endpoint) and insert your receiver api key for `` (see xref:/use/security/k8s-ingestion-api-keys.adoc#_api_keys[here] where to find it): +After installation modify the collector configuration by editing `/etc/otelcol-contrib/config.yaml`. Change the file such that it looks like the `config.yaml` example here, replace `` with your OTLP endpoint (see xref:/setup/otel/otlp-apis.adoc[OTLP API] for your endpoint) and insert your service token for ``: .config.yaml [,yaml] @@ -112,7 +119,7 @@ extensions: # Use the API key from the env for authentication bearertokenauth: scheme: SUSEObservability - token: "" + token: "" exporters: nop: {} debug: {} @@ -194,7 +201,7 @@ You can add new charts to components, for example the service or service instanc == More info -* xref:/use/security/k8s-ingestion-api-keys.adoc[API keys] +* xref:/use/security/k8s-service-tokens.adoc[Service tokens] * xref:/setup/otel/otlp-apis.adoc[Open Telemetry API] * xref:/setup/otel/collector.adoc[Customizing Open Telemetry Collector configuration] * xref:/setup/otel/instrumentation/README.adoc[Open Telemetry SDKs] diff --git a/docs/next/modules/en/pages/setup/security/authentication/file.adoc b/docs/next/modules/en/pages/setup/security/authentication/file.adoc index 70d1b189..cf916afe 100644 --- a/docs/next/modules/en/pages/setup/security/authentication/file.adoc +++ b/docs/next/modules/en/pages/setup/security/authentication/file.adoc @@ -5,7 +5,7 @@ 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 xref:/setup/security/rbac/role_based_access_control.adoc[Role based access control (RBAC) documentation]. +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 xref:/setup/security/rbac/README.adoc[Role based access control (RBAC) documentation]. == Set up file based authentication diff --git a/docs/next/modules/en/pages/setup/security/authentication/oidc.adoc b/docs/next/modules/en/pages/setup/security/authentication/oidc.adoc index f3a26d3b..6db7cf8c 100644 --- a/docs/next/modules/en/pages/setup/security/authentication/oidc.adoc +++ b/docs/next/modules/en/pages/setup/security/authentication/oidc.adoc @@ -18,9 +18,38 @@ The result of this configuration should produce a *clientId* and a *secret*. Cop == Configure SUSE Observability for OIDC +=== Rancher + +To configure Rancher as the OIDC provider for SUSE Observability, you need to add the OIDC details 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 you can use 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 you send to the OIDC provider as custom request parameters. Certain 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 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: +To configure SUSE Observability to use an OIDC authentication provider on Kubernetes, you need to add OIDC details and user role mapping to the file `authentication.yaml`. For example: [,yaml] ---- diff --git a/docs/next/modules/en/pages/setup/security/rbac/README.adoc b/docs/next/modules/en/pages/setup/security/rbac/README.adoc index 856e9a26..1eb637d6 100644 --- a/docs/next/modules/en/pages/setup/security/rbac/README.adoc +++ b/docs/next/modules/en/pages/setup/security/rbac/README.adoc @@ -1,2 +1,33 @@ = Role based access control (RBAC) :description: SUSE Observability Self-hosted + +Access Management helps you manage who has access to the specific topology elements, metric data, traces, 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 you do with RBAC? + +Here are 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, traces, 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 xref:/setup/security/rbac/rbac_permissions.adoc[permissions]. Process of setting up a role in SUSE Observability is described in xref:/setup/security/rbac/rbac_roles.adoc[How to set up roles]. + +== Sources of RBAC roles + +You can define roles in several ways. All use the same xref:/setup/security/rbac/rbac_permissions.adoc[Permissions]. + +* **Configuration** - in the xref:setup/security/rbac/rbac_roles.adoc#_custom_roles_via_the_configuration_file[helm values] for SUSE Observability +* **Dynamic** - xref:setup/security/rbac/rbac_roles.adoc#_custom_roles_via_the_cli[use the `sts` CLI] +* **Mapped from Kubernetes** - xref:/setup/security/rbac/rbac_rancher.adoc[map Kubernetes `Roles` and `RoleBindings`] + +== More on RBAC configuration + +* xref:/setup/security/rbac/rbac_permissions.adoc[Permissions] +* xref:/setup/security/rbac/rbac_roles.adoc[How to set up roles] +* xref:/setup/security/rbac/rbac_rancher.adoc[Use with Rancher] +* xref:/setup/security/rbac/rbac_scopes.adoc[Scopes] +* xref:/setup/security/authentication/README.adoc[How to configure authentication] diff --git a/docs/next/modules/en/pages/setup/security/rbac/rbac_permissions.adoc b/docs/next/modules/en/pages/setup/security/rbac/rbac_permissions.adoc index ddb15183..3727bb65 100644 --- a/docs/next/modules/en/pages/setup/security/rbac/rbac_permissions.adoc +++ b/docs/next/modules/en/pages/setup/security/rbac/rbac_permissions.adoc @@ -16,69 +16,124 @@ Permissions are stored in StackGraph. This means that: == SUSE Observability permissions -There are two types of permission in SUSE Observability. *System permissions* scope user capabilities, such as access to settings, query execution and scripting. *View permissions* allow for CRUD operations on SUSE Observability Views, these can be granted for a specific view or for all views. For details of the permissions attached to each predefined role in SUSE Observability, see xref:/setup/security/rbac/rbac_roles.adoc#_predefined_roles[predefined roles] +There are two types of permission in SUSE Observability. *System permissions* scope user capabilities, such as access to settings, query execution and scripting. *Scoped permissions* determine access to observability data and some resource types like SUSE Observability Views. For CRUD operations on SUSE Observability Views, these can be granted for a specific view or for all views. For details of the permissions attached to each predefined role in SUSE Observability, see xref:/setup/security/rbac/rbac_roles.adoc#_predefined_roles[predefined roles] The following permissions are available in SUSE Observability: -* `access-analytics` - Access the Analytics page in the SUSE Observability UI. -* `access-cli` - Access the CLI page. This provides the API key to use for authentication with the SUSE Observability CLI. -* `access-explore` - Access the Explore page in the SUSE Observability UI. -* `access-log-data` - Access SUSE Observability logs using the CLI. -* `access-synchronization-data` - Access SUSE Observability synchronization status and data using the CLI. -* `access-topic-data` - Access SUSE Observability Receiver data using the CLI. -* `access-view` - A *View permission*. Access a specific view (when granted on a view) or all views (when granted on `everything`). Granted on the following views for predefined SUSE Observability roles: - ** Administrator: `everything` (all views) - ** Platform Administrator: `everything` (all views) - ** Power User: `everything` (all views) - ** Guest: `everything` (all views) -* `create-views` - xref:/use/views/k8s-custom-views.adoc[Create views] in the SUSE Observability UI. -* `delete-view` - A *view permission*. Delete a specific view (when granted on a view) or all views (when granted on `everything`). Granted on the following views for predefined SUSE Observability roles: - ** Administrator: `everything` (all views) - ** Platform Administrator: - - ** Power User: `everything` (all views) - ** Guest: - -* `execute-component-actions` - Execute xref:/use/views/k8s-topology-perspective.adoc#_actions[component actions]. -* `execute-component-templates` - Invoke a component template API extension (internal use only). -* `execute-node-sync` - Reset or delete a synchronization. -* `execute-restricted-scripts` - Execute scripts using the HTTP script API in the SUSE Observability UI analytics environment. Also requires `execute-scripts`. -* `execute-scripts` - Execute a query in the SUSE Observability UI Analytics environment. The `execute-restricted-scripts` permission is also required to execute scripts using the HTTP script API. -* `export-settings` - Export settings. -* `import-settings` - Import settings. -* `manage-annotations` - Persist and fetch Anomaly annotations in SUSE Observability. -* `manage-ingestion-api-keys` - Manage xref:/use/security/k8s-ingestion-api-keys.adoc[API keys] for data ingestion. -* `manage-metric-bindings` - Create, delete and change xref:/use/metrics/k8s-add-charts.adoc[metric bindings] -* `manage-monitors` - Create, delete and change xref:/use/alerting/k8s-monitors.adoc[monitors]. -* `manage-notifications` - Create, delete, and modify xref:/use/alerting/notifications/configure.adoc[notifications]. -* `manage-service-tokens`- Create/delete xref:/use/security/k8s-service-tokens.adoc[Service Tokens] in SUSE Observability. -* `manage-stackpacks` - Install/upgrade/uninstall StackPacks. -* `manage-star-view` - Add and remove stars from views in the SUSE Observability UI. -* `manage-topology-elements` - Create/update/delete topology elements. -* `perform-custom-query` - Access the xref:/use/views/k8s-filters.adoc#_filter_topology[topology filter]. -* `read-agents` - List connected agents with the cli `agent list` command -* `read-permissions` - List all granted permissions across the entire system using the CLI. -* `read-settings` - Access the Settings page in the SUSE Observability UI. -* `read-stackpacks` -* `read-system-notifications` - Access the system notifications in the UI -* `read-telemetry-streams` - Access the telemetry data for components in the StackState UI -* `read-traces` - Read and access trace data. -* `run-monitors` - Execute a xref:/use/alerting/k8s-monitors.adoc[monitor] and make it run periodically. -* `save-view`- A *view permission*. Update a specific view (when granted on a view) or all views (when granted on `everything`). Granted on the following views for predefined StackState roles: - ** Administrator: `everything` (all views) - ** Platform Administrator: - - ** Power User: `everything` (all views) - ** Guest: - -* `unlock-node` - Unlock xref:/stackpacks/about-stackpacks.adoc#_locked_configuration_items[locked configuration items]. -* `update-permissions` - Grant/revoke permissions or change subjects. -* `update-settings` - Update settings. -* `update-visualization` - Change xref:/use/views/k8s-topology-perspective.adoc#_visualization_settings[visualization settings]. -* `upload-stackpacks` - Upload new (versions of) StackPacks. -* `view-metric-bindings` - View xref:/use/metrics/k8s-add-charts.adoc[metric bindings] (via the cli) -* `view-monitors` - View monitor configurations. -* `view-notifications` - View notification settings. +.Permissions +[cols="2,2,5"] +|=== +|Resources |Verbs |Description + +|agents +|get +|Connected agents + +|api-tokens +|get +|The API key to use for authentication with the SUSE Observability CLI. This is unique per user. + +|component-actions +|execute +|xref:/use/views/k8s-topology-perspective.adoc#_actions[Component actions in the topology perspective]. + +|metric-bindings +|get, create, update, delete +|xref:/use/metrics/k8s-add-charts.adoc[Bindings to visualize data in the metrics perspective]. + +|metrics +|get^[1]^, update +|Ingest and query metric data using PromQL + +|monitors +|get, create, update, delete, execute +|xref:/use/alerting/k8s-monitors.adoc[Determine component health with monitors]. + +|notifications +|get, create, update, delete +|xref:/use/alerting/notifications/configure.adoc[Get alerted with notifications]. + +|permissions +|get, update +|Manage permissions on subjects. + +|scoped-permissions +|update^[1]^ +|Manage scoped permissions, granting (or revoking) access to topology, metrics and traces from a single cluster. + +|scripts +|execute +|Execute a script in the SUSE Observability UI Analytics environment. + +|restricted-scripts +|execute +|Use the HTTP script and Gremlin graph API in the Analytics environment. + +|service-token +|get, create, delete +|xref:/use/security/k8s-service-tokens.adoc[Service tokens] authenticate an external service and can be used for data ingestion. + +|settings +|get, update, unlock +|Export or import settings or unlock xref:/stackpacks/about-stackpacks.adoc#_locked_configuration_items[locked configuration items]. + +|stackpacks +|get, update +|List or upload xref:/stackpacks/about-stackpacks.adoc[Stackpacks]. + +|stackpack-configurations +|create, update, delete +|Manage integrations using xref:/stackpacks/about-stackpacks.adoc[Stackpacks]. + +|sync-data +|get, delete +|Inspect or reset the topology and health synchronization pipelines. + +|system-notifications +|get +|Access the system notifications in the UI + +|topic-messages +|get +|Access SUSE Observability Receiver data. + +|topology +|get^[1]^ +|xref:/use/views/k8s-views.adoc[Explore topology scoped views]. + +|traces +|get^[1]^ +|xref:/use/traces/k8sTs-explore-traces.adoc[Explore traces]. + +|views +|get^[1]^, create, update^[1]^, delete^[1]^ +|Use or manage xref:/use/views/k8s-custom-views.adoc[custom views]. + +|favorite-views +|create, delete +|Add and remove stars from views. + +|visualization +|update +|Change xref:/use/views/k8s-topology-perspective.adoc#_visualization_settings[visualization settings]. + +|=== +^[1]^ This is a *scoped permission*, the interpretation of the resource name depends on the context + +=== Scoped permissions + +You can grant certain permissions system-wide, or you can limit them to a subset of the resources. You can give them a *Resource Name*, which indicates the scope. The interpretation of this name is dependent on the type of resource. Note that the scoping may apply to only some of the verbs. + +* `views` - The name of the view +* `topology` - Any component label. In a Kubernetes environment, this can be, for example, `cluster-name:` or `k8s-scope:/` +* `metrics` - In a Kubernetes environment, either `k8s::\\__any__` or `k8s::` +* `traces` - In a Kubernetes environment, either `k8s.cluster.name:` or `k8s.scope:/` +* `scoped-permissions` - The name of the cluster for which permissions are managed == Manage permissions -SUSE Observability permissions can be managed using the `sts` CLI. +You can manage SUSE Observability permissions using the `sts` CLI. +For scoped permissions, a resource name may be specified. If none is given, the permission will be granted (or revoked) system-wide. [NOTE] ==== @@ -86,15 +141,61 @@ SUSE Observability permissions can be managed using the `sts` CLI. ==== -=== List all permissions +=== List all available permissions -List all permissions: +List all available permissions: [,text] ---- sts rbac list-permissions ---- +=== List all subjects + +List all subjects: + +[,text] +---- +sts rbac describe subjects + +SUBJECT | SOURCE +stackstate-admin | Static +suse-observability-instance-admin | Kubernetes +suse-observability-agent-clusterA | Observability +---- +[NOTE] +==== +`The subject `SOURCE` shows who owns and manages the subject. It can be one of our RBAC sources (Configuration|Static, Observability, Kubernetes) + +* Configuration|Static: Subjects obtained via Suse Observability configuration through helm +* Observability: Subjects managed via the sts cli +* Kubernetes: Subjects obtained via RBAC agent from Kubernetes RoleBindings and ClusterRoleBindings +==== + +=== List subjects for a user + +List all subjects that are assigned to the context: + +[,text] +---- +sts user-session roles + +keycloakoidc_group://suse-observability-instance-troubleshooter +keycloakoidc_group://suse-observability-instance-observer +keycloakoidc_group://suse-observability-cluster-observer +keycloakoidc_group://suse-observability-instance-admin +keycloakoidc_group://suse-observability-observer +---- + +List all subjects that are assigned to a user, by providing their `api-token`: + +[,text] +---- +sts user-session roles --api-token [api-token] + +keycloakoidc_group://suse-observability-instance-admin +---- + === Show granted permissions Show the permissions granted to a specific role. @@ -104,7 +205,16 @@ Show the permissions granted to a specific role. sts rbac describe-permissions --subject [role-name] ---- +[NOTE] +==== +`--subject` can be any of the subjects available in the different RBAC sources (Configuration, Observability, Kubernetes) +==== + === Grant permissions +[NOTE] +==== +`--subject` can be an Observability subject, Configuration and Kubernetes subjects are read-only +==== ==== Allow a user to open a view @@ -112,12 +222,12 @@ Give a subject with permission to open a view: [,text] ---- -sts rbac grant --subject [role-name] --permission access-view --resource [view-name] +sts rbac grant --subject [role-name] --permission get-views --resource [view-name] ---- -==== Allow a user to create (save) views +==== Allow a user to create views -Give a subject with the system permission to create (save) views: +Give a subject with the system permission to create views: [,text] ---- @@ -130,25 +240,20 @@ Give a subject with the system permission to check SUSE Observability settings: [,text] ---- -sts rbac grant --subject [role-name] --permission read-settings ----- - -==== Allow a user to add or edit event handlers - -Give a subject with the system permission to add new event handlers and edit existing event handlers: - -[,text] ----- -sts rbac grant --subject [role-name] --permission manage-event-handlers +sts rbac grant --subject [role-name] --permission get-settings ---- === Revoke permissions +[NOTE] +==== +`--subject` can be an Observability subject, Configuration and Kubernetes subjects are read-only +==== Revoke permissions for a subject to open a view: [,text] ---- -sts rbac revoke --subject [role-name] --permission access-view --resource [view-name] +sts rbac revoke --subject [role-name] --permission get-views --resource [view-name] ---- == SUSE Observability UI with no permissions diff --git a/docs/next/modules/en/pages/setup/security/rbac/rbac_rancher.adoc b/docs/next/modules/en/pages/setup/security/rbac/rbac_rancher.adoc new file mode 100644 index 00000000..47709c58 --- /dev/null +++ b/docs/next/modules/en/pages/setup/security/rbac/rbac_rancher.adoc @@ -0,0 +1,144 @@ += Rancher RBAC +: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 xref:/setup/security/rbac/rbac_roles.adoc[How to set up roles] in a standalone installation. + +NOTE: for Rancher RBAC to function, authentication for SUSE Observability must be configured with the xref:setup/security/authentication/oidc.adoc#_rancher[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 xref:/setup/security/rbac/rbac_permissions.adoc[Role based access control (RBAC) permissions] + +[tabs] +==== +Recommended Access:: ++ +-- +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 +|=== + +-- +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 +|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 +|=== + +-- +Administrator:: ++ +-- +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 xref:/setup/security/rbac/rbac_permissions.adoc[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` + +image::rancher-custom-role.png[Custom RoleTemplate for richer access] + +You can specify any resource and verb combination defined in the xref:/setup/security/rbac/rbac_permissions.adoc[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`. \ No newline at end of file diff --git a/docs/next/modules/en/pages/setup/security/rbac/rbac_roles.adoc b/docs/next/modules/en/pages/setup/security/rbac/rbac_roles.adoc index 0c32a971..5f6b1b88 100644 --- a/docs/next/modules/en/pages/setup/security/rbac/rbac_roles.adoc +++ b/docs/next/modules/en/pages/setup/security/rbac/rbac_roles.adoc @@ -28,45 +28,63 @@ Permissions assigned to the predefined Administrator role (`stackstate-admin`) a [,text] ---- -$ ./sts rbac describe-permissions --subject stackstate-admin -PERMISSION | RESOURCE -access-view | everything -delete-view | everything -save-view | everything -access-cli | system -access-explore | system -access-log-data | system -access-synchronization-data | system -access-topic-data | system -create-views | system -execute-component-actions | system -execute-component-templates | system -execute-node-sync | system -execute-restricted-scripts | system -export-settings | system -import-settings | system -manage-annotations | system -manage-event-handlers | system -manage-monitors | system -manage-service-tokens | system -manage-stackpacks | system -manage-star-view | system -manage-telemetry-streams | system -manage-topology-elements | system -perform-custom-query | system -read-agents | system -read-metrics | system -read-permissions | system -read-settings | system -read-stackpacks | system -read-system-notifications | system -read-telemetry-streams | system -run-monitors | system -update-permissions | system -update-settings | system -update-visualization | system -upload-stackpacks | system -view-monitors | system +❯ ./sts rbac describe-permissions --subject stackstate-admin +PERMISSION | RESOURCE +create-dashboards | system +create-favorite-dashboards | system +create-favorite-views | system +create-ingestion-api-keys | system +create-metric-bindings | system +create-monitors | system +create-notifications | system +create-service-tokens | system +create-stackpack-configurations | system +create-views | system +delete-dashboards | system +delete-favorite-dashboards | system +delete-favorite-views | system +delete-ingestion-api-keys | system +delete-metric-bindings | system +delete-monitors | system +delete-notifications | system +delete-service-tokens | system +delete-stackpack-configurations | system +delete-sync-data | system +delete-views | system +execute-component-actions | system +execute-monitors | system +execute-restricted-scripts | system +execute-scripts | system +get-agents | system +get-api-tokens | system +get-dashboards | system +get-ingestion-api-keys | system +get-metric-bindings | system +get-metrics | system +get-monitors | system +get-notifications | system +get-permissions | system +get-service-tokens | system +get-settings | system +get-stackpacks | system +get-sync-data | system +get-system-notifications | system +get-topic-messages | system +get-topology | system +get-traces | system +get-views | system +update-dashboards | system +update-metric-bindings | system +update-metrics | system +update-monitors | system +update-notifications | system +update-permissions | system +update-scoped-permissions | system +update-settings | system +update-stackpack-configurations | system +update-stackpacks | system +update-views | system +update-visualization | system ---- -- @@ -78,47 +96,58 @@ The Power User role (`stackstate-power-user`) has all Administrator permissions, * `execute-restricted-scripts` * `update-permissions` -* `upload-stackpacks` +* `update-stackpacks` Permissions assigned to the predefined Power User role (`stackstate-power-user`) are listed below, these were retrieved using the `sts` CLI. For details of the different permissions and how to manage them using the `sts` CLI, see xref:/setup/security/rbac/rbac_permissions.adoc[RBAC permissions]. [,text] ---- ❯ ./sts rbac describe-permissions --subject stackstate-power-user -PERMISSION | RESOURCE -access-view | everything -delete-view | everything -save-view | everything -access-cli | system -access-explore | system -access-log-data | system -access-synchronization-data | system -access-topic-data | system -create-views | system -execute-component-actions | system -execute-component-templates | system -execute-node-sync | system -export-settings | system -import-settings | system -manage-annotations | system -manage-event-handlers | system -manage-monitors | system -manage-stackpacks | system -manage-star-view | system -manage-telemetry-streams | system -manage-topology-elements | system -perform-custom-query | system -read-agents | system -read-metrics | system -read-permissions | system -read-settings | system -read-stackpacks | system -read-system-notifications | system -read-telemetry-streams | system -run-monitors | system -update-settings | system -update-visualization | system -view-monitors | system +PERMISSION | RESOURCE +create-dashboards | system +create-favorite-dashboards | system +create-favorite-views | system +create-metric-bindings | system +create-monitors | system +create-notifications | system +create-stackpack-configurations | system +create-views | system +delete-dashboards | system +delete-favorite-dashboards | system +delete-favorite-views | system +delete-metric-bindings | system +delete-monitors | system +delete-notifications | system +delete-stackpack-configurations | system +delete-sync-data | system +execute-component-actions | system +execute-monitors | system +execute-scripts | system +get-agents | system +get-api-tokens | system +get-dashboards | system +get-metric-bindings | system +get-metrics | system +get-monitors | system +get-notifications | system +get-permissions | system +get-settings | system +get-stackpacks | system +get-sync-data | system +get-system-notifications | system +get-topic-messages | system +get-topology | system +get-traces | system +get-views | system +update-dashboards | system +update-metric-bindings | system +update-metrics | system +update-monitors | system +update-notifications | system +update-settings | system +update-stackpack-configurations | system +update-views | system +update-visualization | system ---- -- @@ -133,40 +162,40 @@ Permissions assigned to the predefined troubleshooter role are listed below, the [,text] ---- ❯ ./sts rbac describe-permissions --subject stackstate-k8s-troubleshooter -PERMISSION | RESOURCE -access-view | everything -delete-view | everything -save-view | everything -access-cli | system -access-explore | system -access-log-data | system -access-synchronization-data | system -access-topic-data | system -create-views | system -execute-component-actions | system -execute-component-templates | system -execute-node-sync | system -export-settings | system -import-settings | system -manage-annotations | system -manage-event-handlers | system -manage-monitors | system -manage-stackpacks | system -manage-star-view | system -manage-telemetry-streams | system -manage-topology-elements | system -perform-custom-query | system -read-agents | system -read-metrics | system -read-permissions | system -read-settings | system -read-stackpacks | system -read-system-notifications | system -read-telemetry-streams | system -run-monitors | system -update-settings | system -update-visualization | system -view-monitors | system +PERMISSION | RESOURCE +create-dashboards | system +create-favorite-dashboards | system +create-favorite-views | system +create-monitors | system +create-notifications | system +create-views | system +delete-dashboards | system +delete-favorite-dashboards | system +delete-favorite-views | system +delete-monitors | system +delete-notifications | system +delete-views | system +execute-monitors | system +get-agents | system +get-api-tokens | system +get-dashboards | system +get-metric-bindings | system +get-metrics | system +get-monitors | system +get-notifications | system +get-permissions | system +get-settings | system +get-stackpacks | system +get-system-notifications | system +get-topic-messages | system +get-traces | system +get-views | system +update-dashboards | system +update-monitors | system +update-notifications | system +update-stackpacks | system +update-views | system +update-visualization | system ---- -- @@ -181,31 +210,38 @@ Permissions assigned to the predefined Guest role are listed below, these were r [,text] ---- ❯ ./sts rbac describe-permissions --subject stackstate-guest -PERMISSION | RESOURCE -access-view | everything -access-cli | system -access-explore | system -execute-component-actions | system -manage-star-view | system -perform-custom-query | system -read-metrics | system -read-permissions | system -read-settings | system -read-system-notifications | system -read-telemetry-streams | system -update-visualization | system -view-monitors | system +PERMISSION | RESOURCE +create-dashboards | system +create-favorite-dashboards | system +create-favorite-views | system +delete-dashboards | system +delete-favorite-dashboards | system +delete-favorite-views | system +get-api-tokens | system +get-dashboards | system +get-metric-bindings | system +get-metrics | system +get-monitors | system +get-notifications | system +get-permissions | system +get-settings | system +get-system-notifications | system +get-topic-messages | system +get-traces | system +get-views | system +update-dashboards | system +update-visualization | system ---- -- ==== -== Custom roles +== Custom roles (Configuration RBAC) In addition to the predefined roles (`stackstate-admin`, `stackstate-power-user`, `stackstate-k8s-troubleshooter`, `stackstate-guest`), which are always available, custom roles can be added. There are multiple ways to add custom roles: . via the configuration file, with the same permission as the predefined roles -. via the configuration file, with a custom scope and custom system and view permissions +. via the configuration file, with a custom permissions . using the `sts` CLI, the subjects and their permissions are stored in the database and can be modified during runtime Roles added via the configuration file require a restart and therefore result in a short period of downtime. Roles created using the CLI are stored in the database and can be modified at runtime. @@ -238,7 +274,7 @@ suse-observability \ suse-observability/suse-observability ---- -=== Custom roles with custom scopes and permissions via the configuration file +=== Custom roles via the configuration file To set up a new role called `development-troubleshooter`, which will allow the same permissions as the predefined troubleshooter role, but only for the `dev-test` cluster, include this YAML snippet in an `authentication.yaml`: @@ -250,32 +286,42 @@ stackstate: custom: development-troubleshooter: systemPermissions: - - access-cli + - create-dashboards + - create-favorite-dashboards + - create-favorite-views + - create-monitors + - create-notifications - create-views - - execute-component-actions - - export-settings - - manage-monitors - - manage-notifications - - manage-stackpacks - - manage-star-view - - perform-custom-query - - read-agents - - read-metrics - - read-permissions - - read-settings - - read-system-notifications - - read-telemetry-streams - - read-traces - - run-monitors + - delete-dashboards + - delete-favorite-dashboards + - delete-favorite-views + - delete-monitors + - delete-notifications + - delete-views + - execute-monitors + - get-agents + - get-api-tokens + - get-dashboards + - get-metric-bindings + - get-metrics + - get-monitors + - get-notifications + - get-permissions + - get-settings + - get-stackpacks + - get-system-notifications + - get-topic-messages + - get-traces + - get-views + - update-dashboards + - update-monitors + - update-notifications + - update-stackpacks + - update-views - update-visualization - - view-metric-bindings - - view-monitors - - view-notifications - viewPermissions: - - access-view - - save-view - - delete-view - topologyScope: "label = 'kube_cluster_name:dev-test'" # Optional, leave out when the scope should be all topology + resourcePermissions: + get-topology: + - "cluster-name:dev-test" ---- To use it in for your SUSE Observability installation (or already running instance, note that it will restart the API): @@ -291,7 +337,7 @@ suse-observability \ suse-observability/suse-observability ---- -=== Custom roles via the CLI +=== Custom roles via the CLI (Observability RBAC) 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: @@ -299,41 +345,48 @@ To set up a new role called `development-troubleshooter`, which will allow the s + [,text] ---- -sts rbac create-subject --subject development-troubleshooter --scope 'label = "kube_cluster_name:dev-test"' +sts rbac create-subject --subject development-troubleshooter +sts rbac grant --subject development-troubleshooter --permission get-topology --resource "cluster-name:dev-test"' ---- + -Please note that when passing an topology query in a CLI command, all operators (like `=`, `<`,`AND`, and so on) need to be surrounded by spaces, as in the above example. . Configured subjects need permissions to access parts of the UI and to execute actions in it. To grant the same permissions as the troubleshooter role, follow the below example: + [,text] ---- - # To grant permission to access any view use the special view name 'everything' - sts rbac grant --subject development-troubleshooter --permission access-view --resource "everything" - sts rbac grant --subject development-troubleshooter --permission save-view --resource "everything" - sts rbac grant --subject development-troubleshooter --permission delete-view --resource "everything" - - sts rbac grant --subject development-troubleshooter --permission access-cli - sts rbac grant --subject development-troubleshooter --permission create-views - sts rbac grant --subject development-troubleshooter --permission execute-component-actions - sts rbac grant --subject development-troubleshooter --permission export-settings - sts rbac grant --subject development-troubleshooter --permission manage-monitors - sts rbac grant --subject development-troubleshooter --permission manage-notifications - sts rbac grant --subject development-troubleshooter --permission manage-stackpacks - sts rbac grant --subject development-troubleshooter --permission manage-star-view - sts rbac grant --subject development-troubleshooter --permission perform-custom-query - sts rbac grant --subject development-troubleshooter --permission read-agents - sts rbac grant --subject development-troubleshooter --permission read-metrics - sts rbac grant --subject development-troubleshooter --permission read-permissions - sts rbac grant --subject development-troubleshooter --permission read-settings - sts rbac grant --subject development-troubleshooter --permission read-system-notifications - sts rbac grant --subject development-troubleshooter --permission read-telemetry-streams - sts rbac grant --subject development-troubleshooter --permission read-traces - sts rbac grant --subject development-troubleshooter --permission run-monitors - sts rbac grant --subject development-troubleshooter --permission update-visualization - sts rbac grant --subject development-troubleshooter --permission view-metric-bindings - sts rbac grant --subject development-troubleshooter --permission view-monitors - sts rbac grant --subject development-troubleshooter --permission view-notifications +sts rbac grant --subject development-troubleshooter --permission create-dashboards +sts rbac grant --subject development-troubleshooter --permission create-favorite-dashboards +sts rbac grant --subject development-troubleshooter --permission create-favorite-views +sts rbac grant --subject development-troubleshooter --permission create-monitors +sts rbac grant --subject development-troubleshooter --permission create-notifications +sts rbac grant --subject development-troubleshooter --permission create-views +sts rbac grant --subject development-troubleshooter --permission delete-dashboards +sts rbac grant --subject development-troubleshooter --permission delete-favorite-dashboards +sts rbac grant --subject development-troubleshooter --permission delete-favorite-views +sts rbac grant --subject development-troubleshooter --permission delete-monitors +sts rbac grant --subject development-troubleshooter --permission delete-notifications +sts rbac grant --subject development-troubleshooter --permission delete-views +sts rbac grant --subject development-troubleshooter --permission execute-monitors +sts rbac grant --subject development-troubleshooter --permission get-agents +sts rbac grant --subject development-troubleshooter --permission get-api-tokens +sts rbac grant --subject development-troubleshooter --permission get-dashboards +sts rbac grant --subject development-troubleshooter --permission get-metric-bindings +sts rbac grant --subject development-troubleshooter --permission get-metrics +sts rbac grant --subject development-troubleshooter --permission get-monitors +sts rbac grant --subject development-troubleshooter --permission get-notifications +sts rbac grant --subject development-troubleshooter --permission get-permissions +sts rbac grant --subject development-troubleshooter --permission get-settings +sts rbac grant --subject development-troubleshooter --permission get-stackpacks +sts rbac grant --subject development-troubleshooter --permission get-system-notifications +sts rbac grant --subject development-troubleshooter --permission get-topic-messages +sts rbac grant --subject development-troubleshooter --permission get-traces +sts rbac grant --subject development-troubleshooter --permission get-views +sts rbac grant --subject development-troubleshooter --permission update-dashboards +sts rbac grant --subject development-troubleshooter --permission update-monitors +sts rbac grant --subject development-troubleshooter --permission update-notifications +sts rbac grant --subject development-troubleshooter --permission update-stackpacks +sts rbac grant --subject development-troubleshooter --permission update-views +sts rbac grant --subject development-troubleshooter --permission update-visualization ---- Please note that the subject's name, as well as permissions, are case-sensitive. diff --git a/docs/next/modules/en/pages/setup/security/rbac/rbac_scopes.adoc b/docs/next/modules/en/pages/setup/security/rbac/rbac_scopes.adoc index 5b0b438f..ad90dd57 100644 --- a/docs/next/modules/en/pages/setup/security/rbac/rbac_scopes.adoc +++ b/docs/next/modules/en/pages/setup/security/rbac/rbac_scopes.adoc @@ -1,27 +1,29 @@ -= Scopes += Topology Scopes :description: SUSE Observability Self-hosted -== How do scopes work? +WARNING: Topology scoping by query is deprecated functionality. It is superseded by the `get-topology` permission that can grant access to any component with a specific label. -The scope is an xref:/develop/reference/k8sTs-stql_reference.adoc[STQL query] 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? -NOTE: Please note that function calls like `withCauseOf` and `withNeighborsOf` aren't supported as they would not be performant in this context. +The topology scope is an xref:/develop/reference/k8sTs-stql_reference.adoc[STQL query] that's combined with the `get-topology` permissions as a prefix to every topology query executed in SUSE Observability. When a user wants to select a view or pass a query in SUSE Observability, this prefix query runs as part of the user's query. This limits the results to match the user's role. -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. +NOTE: Function calls like `withCauseOf` and `withNeighborsOf` aren't supported as they would not be performant in this context. -Users need to log out and authenticate again to SUSE Observability whenever any changes to roles or permissions are made. +If a user belongs to multiple groups, they can have multiple topology scopes, translating to multiple prefixes. Here, the prefix is executed as an OR of all topology scopes the user has. -== Why scopes? +Users need to log out and authenticate again to SUSE Observability whenever their roles or permissions change. -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. +== Why topology scopes? -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 xref:/setup/security/rbac/rbac_permissions.adoc#_predefined_roles[predefined roles] instead. +Topology scopes are a security feature for subjects within SUSE Observability. The predefined SUSE Observability roles Administrator, Power User and Guest have no topology scope defined. + +It's possible to specify a topology scope as a query wildcard, however, this results 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 xref:/setup/security/rbac/rbac_permissions.adoc#_predefined_roles[predefined roles] instead. == Examples The below example shows the same topology view called "All Infrastructure" for four users with different permission levels. -=== This user is a part of SUSE Observability Admin group, so there is no scope: +=== This user is a part of SUSE Observability Admin group, so there is no topology scope: image::v51_allperm.png[Full view permissions] @@ -32,7 +34,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] ---- @@ -48,7 +50,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] ---- diff --git a/docs/next/modules/en/pages/setup/security/rbac/role_based_access_control.adoc b/docs/next/modules/en/pages/setup/security/rbac/role_based_access_control.adoc deleted file mode 100644 index 326fc38a..00000000 --- a/docs/next/modules/en/pages/setup/security/rbac/role_based_access_control.adoc +++ /dev/null @@ -1,24 +0,0 @@ -= Role-based access control (RBAC) -:description: SUSE Observability Self-hosted - -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 xref:/setup/security/rbac/rbac_permissions.adoc[permissions]. Process of setting up a role in SUSE Observability is described in xref:/setup/security/rbac/rbac_roles.adoc[How to set up roles]. - -== More on RBAC configuration - -* xref:/setup/security/rbac/rbac_permissions.adoc[Permissions] -* xref:/setup/security/rbac/rbac_roles.adoc[How to set up roles] -* xref:/setup/security/rbac/rbac_scopes.adoc[Scopes] -* xref:/setup/security/authentication/README.adoc[How to configure authentication] diff --git a/docs/next/modules/en/pages/use/metrics/k8s-stackstate-grafana-datasource.adoc b/docs/next/modules/en/pages/use/metrics/k8s-stackstate-grafana-datasource.adoc index 671e3c8d..d7431a20 100644 --- a/docs/next/modules/en/pages/use/metrics/k8s-stackstate-grafana-datasource.adoc +++ b/docs/next/modules/en/pages/use/metrics/k8s-stackstate-grafana-datasource.adoc @@ -13,13 +13,13 @@ You can do this via the SUSE Observability CLI: ---- > sts rbac create-subject --subject grafana ✅ Created subject 'grafana' -> sts rbac grant --subject grafana --permission read-metrics -✅ Granted permission 'read-metrics' on 'system' to subject 'grafana' -PERMISSION | RESOURCE -read-metrics | system +> sts rbac grant --subject grafana --permission get-metrics +✅ Granted permission 'get-metrics' on 'system' to subject 'grafana' +PERMISSION | RESOURCE +get-metrics | system ---- -This will create a new role in SUSE Observability called `grafana` and grant it the `read-metrics` permission. You can then create a ServiceToken for this role: +This will create a new role in SUSE Observability called `grafana` and grant it the `get-metrics` permission. You can then create a ServiceToken for this role: [,sh] ---- @@ -48,3 +48,34 @@ On the datasource configuration page, enter the following configuration details: image::k8s/k8s-grafana-datasource.png[Grafana datasource configuration] Click on the `Save & Test` button to save the datasource. If the configuration is correct, you should see a green `Data source is working` message. + +== Restrict access to metrics + +When you use xref:/setup/security/rbac/rbac_rancher.adoc[Rancher RBAC], it is possible to grant access to metrics on a cluster or namespace level. + +To grant access to all metrics from a cluster: +[,sh] +---- +> sts rbac grant --subject grafana --permission get-metrics --resource k8s:YOUR_CLUSTER:__any__ +✅ Granted permission 'get-metrics' on 'k8s:YOUR_CLUSTER:__any__' to subject 'grafana' +PERMISSION | RESOURCE +get-metrics | k8s:YOUR_CLUSTER:__any__ +---- + +To grant access to all metrics from a namespace: +[,sh] +---- +> sts rbac grant --subject grafana --permission get-metrics --resource k8s:OTHER_CLUSTER:SINGLE_NAMESPACE +✅ Granted permission 'get-metrics' on 'k8s:OTHER_CLUSTER:SINGLE_NAMESPACE' to subject 'grafana' +PERMISSION | RESOURCE +get-metrics | k8s:OTHER_CLUSTER:SINGLE_NAMESPACE +---- + +Inspect all permissions that have been granted to the subject: +[,sh] +---- +> sts rbac describe-permissions --subject grafana +PERMISSION | RESOURCE +get-metrics | k8s:OTHER_CLUSTER:YOUR_NAMESPACE +get-metrics | k8s:YOUR_CLUSTER:__any__ +---- diff --git a/docs/next/modules/en/pages/use/security/k8s-ingestion-api-keys.adoc b/docs/next/modules/en/pages/use/security/k8s-ingestion-api-keys.adoc index 30c4fa5d..4ff6c5fd 100644 --- a/docs/next/modules/en/pages/use/security/k8s-ingestion-api-keys.adoc +++ b/docs/next/modules/en/pages/use/security/k8s-ingestion-api-keys.adoc @@ -1,10 +1,11 @@ = API Keys :description: SUSE Observability -API keys are used for sending telemetry data to SUSE Observability. It now offers two types of API keys: +API keys are used for sending telemetry data to SUSE Observability. There are three types of API keys: -* Receiver API Key: This key is typically generated during the initial installation of your SUSE Observability instance, and it never expires -* Ingestion API Key: You can create Ingestion API Keys using the SUSE Observability CLI (STS). These keys offer expiration dates, requiring periodic rotation for continued functionality. +* **Service Token** - With this key you can scope the data to be ingested. It also offers expiration dates. See xref:/use/security/k8s-service-tokens.adoc#_authenticate_using_service_tokens_for_data_ingestion[Service Tokens]. +* **Receiver API Key** - This key is typically generated during the initial installation of your SUSE Observability instance, and it never expires. +* **Ingestion API Key** (Deprecated) - You can create Ingestion API Keys using the SUSE Observability CLI (STS). These keys offer expiration dates, requiring periodic rotation for continued functionality. The receiver API key can be found in your `values.yaml` as the `receiverApiKey`, but you can also find it in the installation instructions of the stackpacks. For example if you installed the Kubernetes stackpack: @@ -16,5 +17,8 @@ The receiver API key can be found in your `values.yaml` as the `receiverApiKey`, == Ingestion API Keys (`Deprecated`) Ingestion API Keys were used by external tools to ingest data (such as metrics, events and traces) to the SUSE Observability cluster. -These tools include the STS Agent or/and OTel Collector. Currently, the recommended authentication mechanism is through xref:/use/security/k8s-service-tokens.adoc#_authenticate_using_service_tokens_for_data_ingestion[Service Tokens]. +These tools include the STS Agent or/and OTel Collector. The recommended authentication mechanism is through xref:/use/security/k8s-service-tokens.adoc#_authenticate_using_service_tokens_for_data_ingestion[Service Tokens]. +== More info + +* xref:/use/security/k8s-service-tokens.adoc[Service tokens] diff --git a/docs/next/modules/en/pages/use/security/k8s-service-tokens.adoc b/docs/next/modules/en/pages/use/security/k8s-service-tokens.adoc index 1648f159..e9dc1a6f 100644 --- a/docs/next/modules/en/pages/use/security/k8s-service-tokens.adoc +++ b/docs/next/modules/en/pages/use/security/k8s-service-tokens.adoc @@ -27,6 +27,11 @@ Use "sts service-token [command] --help" for more information about a command. === Create service tokens +[NOTE] +==== +The Open Telemetry and Kubernetes StackPacks let you create a subject and service token with all required permissions set up. +==== + To create a service token in your instance of SUSE Observability, you can use the `sts` CLI. [,sh] @@ -129,6 +134,16 @@ PERMISSION | RESOURCE update-metrics | system ---- +If you want to use the service token to ingest Kubernetes RBAC data, you also need to grant `update-scoped-permissions`: +[,sh] +---- +> sts rbac grant --subject my-agent --permission update-scoped-permissions --resource my-cluster +✅ Granted permission 'update-scoped-permissions' on 'my-cluster' to subject 'my-agent' +PERMISSION | RESOURCE +update-metrics | system +update-scoped-permissions | my-cluster +---- + This will create a new role in SUSE Observability called `my-agent` and grant it the `update-metrics` permission. You can then create a ServiceToken for this role: [,sh]