[DO NOT MERGE YET] Staging-2.12. Should be merged when rancher 2.12 is released (RBAC mostly)

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]

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

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 `<SERVICE_TOKEN>`.
+
+=== 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='<suse-observability-api-key>'
+    --from-literal=API_KEY='<SERVICE_TOKEN>'
 ----
 
 === 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]

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 `<SERVICE_TOKEN>`.
+
+=== 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='<suse-observability-api-key>'
+    --from-literal=API_KEY='<SERVICE_TOKEN>'
 ----
 
 === 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]

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 `<SERVICE_TOKEN>`.
+
+=== 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='<suse-observability-api-key>'
+    --from-literal=API_KEY='<SERVICE_TOKEN>'
 ----
 
 === 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]

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 `<SERVICE_TOKEN>`.
 
 === 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 `<otlp-suse-observability-endpoint:port>` with your OTLP endpoint (see xref:/setup/otel/otlp-apis.adoc[OTLP API] for your endpoint) and insert your receiver api key for `<receiver-api-key>` (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 `<otlp-suse-observability-endpoint:port>` with your OTLP endpoint (see xref:/setup/otel/otlp-apis.adoc[OTLP API] for your endpoint) and insert your service token for `<SERVICE_TOKEN>`:
 
 .config.yaml
 [,yaml]
@@ -112,7 +119,7 @@ extensions:
   # Use the API key from the env for authentication
   bearertokenauth:
     scheme: SUSEObservability
-    token: "<receiver-api-key>"
+    token: "<SERVICE_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]

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
 

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: "<oidc-client-id>"
+      secret: "<oidc-secret>"
+      baseUrl: "<rancher-url>"
+----
+You can override and extend the OIDC config for Rancher with the following fields:
+
+* **discoveryUri** - URI that 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]
 ----

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]