File-based

SUSE Observability Self-hosted

Overview

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.

Set up file based authentication

Kubernetes

To configure file based authentication on Kubernetes, SUSE Observability users need to be added to the authentication.yaml file. For example:


stackstate:
  authentication:
    file:
      logins:
        - username: admin
          passwordHash: 5f4dcc3b5aa765d61d8327deb882cf99
          roles: [ stackstate-admin ]
        - username: guest
          passwordHash: 5f4dcc3b5aa765d61d8327deb882cf99
          roles: [ stackstate-guest ]
        - username: poweruser
          passwordHash: 5f4dcc3b5aa765d61d8327deb882cf99
          roles: [ stackstate-power-user ]
        - username: troubleshooter
          passwordHash: 5f4dcc3b5aa765d61d8327deb882cf99
          roles: [ stackstate-k8s-troubleshooter ]

Follow the steps below to configure users and apply changes:

In authentication.yaml - add users. The following configuration should be added for each user (see the example above):
- username - the username used to log into SUSE Observability. Only alphanumeric and _ characters are allowed.
- passwordHash - the password used to log into SUSE Observability. Passwords are stored as a bcrypt hash.
- roles - the list of roles that the user is a member of. The default SUSE Observability roles are stackstate-admin, stackstate-power-user and stackstate-guest, for details on how to create other roles, see RBAC roles.
Store the file authentication.yaml together with the file values.yaml from the SUSE Observability installation instructions.

Run a Helm upgrade to apply the changes:

 helm upgrade \
   --install \
   --namespace suse-observability \
   --values values.yaml \
   --values authentication.yaml \
 suse-observability \
 suse-observability/suse-observability

Note:

A bcrypt password hash can be generated using the following command line htpasswd -bnBC 10 "" <password> | tr -d ':\n' or using an online tool.
The first run of the helm upgrade command will result in pods restarting, which may cause a short interruption of availability.
Include authentication.yaml on every helm upgrade run.
The authentication configuration is stored as a Kubernetes secret.

Follow the steps below to configure users and apply changes:

In authentication.yaml - add users. The following configuration should be added for each user (see the example above):
- username - the username used to log into SUSE Observability. Only alphanumeric and _ characters are allowed.
- password - the password used to log into SUSE Observability. Passwords are stored as either an MD5 hash or a bcrypt hash.
- roles - the list of roles that the user is a member of. The default SUSE Observability roles are stackstate-admin, stackstate-power-user, stackstate-k8s-troubleshooter and stackstate-guest, for details on how to create other roles, see RBAC roles.
Restart SUSE Observability to apply the changes.

Note:

An MD5 password hash can be generated using the md5sum or md5 command line applications on Linux and Mac.
A bcrypt password hash can be generated using the following command line htpasswd -bnBC 10 "" <password> | tr -d ':\n' or using an online tool.

Using an external secret

When the user passwords should come from an external secret, follow these steps but fill in the following data:

kind: Secret
metadata:
   name: "<custom-secret-name>"
type: Opaque
data:
  file_<username1>_password: <base64 of bcrypt of password>
  file_<username2>_password: <base64 of bcrypt of password>

For every user in the logins section, a record should be added to the secret, filling in the template. For example:


stackstate:
  authentication:
    file:
      logins:
        - username: admin_user
          roles: [ stackstate-admin ]


kind: Secret
metadata:
   name: "<custom-secret-name>"
type: Opaque
data:
   file_admin_user_password: "base64EncryptedPass"