Access Rights

Authentication types and their configuration

Deckhouse Optics provides various authentication methods to ensure secure access to the system.

The following authentication options are available::

• Email-Password — a standard authentication method where users log in using their email and password. This method is enabled by default.
• External Authentication — authentication method for instance that prefer to use their existing identity management systems. Deckhouse Optics provides authentication through external sources, the following methods are supported:
  • OIDC (OpenID Connect) — a modern authentication standard based on the OAuth 2.0 protocol.
  • LDAP/Active Directory using Dex — integration with corporate LDAP or Active Directory directories using Dex as an intermediary. Integration requires additional configuration on the Deckhouse Kubernetes Platform’s side.
• API token — authentication method for interaction with the system via API. This type of authentication is always enabled.

The authentication method is selected using the ui.auth.mode ModuleConfig parameter of the observability-platform during system installation. When using external authentication (ui.auth.mode: externalAuth), additional role mapping configuration is required.

The user role model

A user is an account in the system that has various access rights to different entities within the system. Users interact with the system through the web interface only.

5 types of roles are provided for a user:

• Super Administrator
• Auditor — read-only Super Administrator, assigned only at the Global level
• Admin
• User
• Viewer

Table of composition of user role rights:

All project members (Viewer, User, Admin) see the project limits. Only the Super Administrator changes the project limits and the limit template that new projects receive.

External authentication

Enabling external authentication

External authentication allows Deckhouse Optics users to use accounts from external systems to log in. To configure the feature, follow these steps:

1. Set the mapping for the Super Administrator role:

   • Go to “System settings” → “Role mappings”.
   • Click “Add Role Mapping”.
   • Fill in the fields:
     • Group name — the identifier of the external group (e.g., “super-administrator”).
     • Object type — select “Global”.
     • Role — select “Super Administrator”.
   • Confirm your choice by clicking “Save”.

2. Enable external authorization:

   • If using Dex, preliminary configuration of dexProvider is required.

   • If OIDC is enabled, configure oidc settings in the ui.authModuleConfig observability-platform.

     An example:

     kubectl patch ModuleConfig observability-platform --type=merge -p <<- 'EOT'
       {
         "spec": {
           "settings": {
             "ui": {
               "auth": {
                 "mode": "externalAuth",
                 "provider": "dex",
                 "issuer": "https://dex.dop.example.com",
                 "groupsParamName": "groups"
               }
             }
           }
         }
       }
     EOT

     You can find more information about the configuration parameters in the documentation.

   • Enable external authorization using the command:

     kubectl patch ModuleConfig observability-platform --type=merge -p <<- 'EOT'
       {
         "spec": {
           "settings": {
             "ui": {
               "auth": {
                 "mode": "externalAuth"
               }
             }
           }
         }
       }
     EOT

When these steps are complete, the system will be ready for using external authentication.

Setting up role mapping

Follow the steps below to set up role mapping:

1. Go to “System settings” → “Role mappings”.
2. Click “Add Role Mapping”:
   • Group name — the name of the group from the external system (e.g., “admins”).
   • Object type — one of three: “Global” (the entire system), “Space”, “Project”.
   • Parent object — the space of the project (for “Project” only).
   • Object name — the name of the space or project (for “Space” and “Project”).
   • Role — “Super Administrator” or “Auditor” (for “Global” only), “Admin”, “User”, “Viewer”.
3. Click “Save”.

When a user signs in through external authentication, their roles are exactly the ones the mapping gives for their groups. Roles not given by the mapping, including roles assigned manually, are removed at sign-in.

If several of the user’s groups match mappings for the same object, the senior role wins. Admin is senior to User, and User is senior to Viewer. At the Global level, Super Administrator is senior to every other role, and Auditor is senior to User and Viewer.

API tokens role model

API token is an account in the system that has various access rights to different entities within the system. It interacts with the system exclusively through the API.

A token can be bind to a global scope, space(s) or project(s).

A multitenant API token is a token whose scope is a workspace, an instance, or several projects at once. Multitenant tokens are limited to the ability to only read monitoring data from the selected scope.

Control tokens (Spaces control, Projects control, Rules control etc) not allowed to have Metrics, Logs, or Traces rights.