Access Management

Description

Access management uses the RBAC (Role-Based Access Control) model — a model based on user roles. Instead of each user receiving an individual set of permissions, access rights are grouped into roles, and users gain access based on their roles.

How RBAC Works

1. Defining Roles:
   Roles are defined to correspond to different duties and functions within the system.
2. Defining Permissions for Roles:
   Permissions that should be granted to each role are defined.
3. Assigning Roles to Users:
   Users are assigned roles corresponding to their duties and functions.
4. Access Control:
   The system uses the role model to control access to resources based on the roles assigned to users.

Glossary

• Users — user accounts in the Deckhouse Commander database.
• Groups — group accounts in the Deckhouse Commander database.
• Roles — define a list of allowed actions on certain types of resources.
• Bindings — link roles to users or groups.
• Resources — Deckhouse Commander objects to which access permissions can be applied.
• Permissions — describe specific actions that can be performed on resources.

Supported Deckhouse Commander Resources

• users — Users
• groups — Groups
• globalroles — Global roles
• globalrolebindings — Global bindings
• workspaces — Workspaces
• workspaceroles — Workspace roles
• workspacerolebindings — Workspace role bindings
• clusters — Clusters
• clustertemplates — Cluster templates
• authtokens — Tokens
• catalogs — Inventory

Read-Only

• workspaceroles/audit — Workspace roles change history
• workspacerolebindings/audit — Workspace bindings change history
• clusters/audit — Clusters change history
• clustertemplates/audit — Templates change history
• authtokens/audit — Tokens change history
• catalogs/audit — Inventory change history

Roles and Bindings

Global roles and bindings operate at the global level for all Deckhouse Commander resources, and Kubernetes resources are created in all clusters managed by Deckhouse Commander. For each role, a ClusterRole with specified Kubernetes rules is created, and for each binding, a ClusterRoleBinding is created.
Resources are translated with the prefix d8:commander:. For example, the viewer role is created in all clusters as ClusterRole/d8:commander:viewer. The same rule applies to role bindings and their corresponding ClusterRoleBinding resource.

Workspace roles and bindings operate at the level of a specific workspace, and Kubernetes resources are created in all clusters of that workspace. For each role, a ClusterRole with specified Kubernetes rules is created, and for each binding, a ClusterRoleBinding is created.
Workspace-level resources are translated with the prefix d8:commander:workspace:, e.g., the viewer role is created in all workspace clusters as ClusterRole/d8:commander:workspace:viewer. The same rule applies for workspace role bindings and the corresponding ClusterRoleBinding resource.

In clusters, a special resource group “Access Rights” is created, which is automatically populated with the current roles and bindings (both global and workspace level). These manifests — ClusterRole and ClusterRoleBinding — are kept up to date in the clusters by an agent (commander-agent module). All role bindings, changes, and deletions in clusters are updated automatically.
The platform interface (Cluster → “Administration” tab) adapts according to the user’s permissions in that cluster.

UI

Global Permissions Settings Panel

This page is accessible from the Workspaces panel (/workspaces) by selecting the “Users and Permissions” menu item in the header.

• “Users” tab — view the list of users and their groups registered in Deckhouse Commander
• “Groups” tab — view the list of groups and their members registered in Deckhouse Commander
• “Roles” tab — role management
• “Bindings” tab — bindings management

Workspace Permissions Settings Panel

This page is accessible from the “Users and Permissions” menu item in the header inside a workspace.

Content is similar to the Global Permissions Settings Panel, but for users and groups of the worksapce.

Configuration

Requirements for Access Management in Deckhouse Commander

• Configured integration with an external IdP via dex-provider.
• A role and binding¹ created for a user or group in the Deckhouse Commander interface.
• User logged in via Dex.

Enabling RBAC Support in Deckhouse Commander

When access management is enabled, all users and groups who previously used Deckhouse Commander automatically become administrators.
This preserves privilege compatibility for existing users and groups but allows restricting them.

To activate access management, set permissionsEnabled: true in the featureFlags field of the ModuleConfig:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: commander
spec:
  enabled: true
  version: 1
  settings:
    featureFlags:
      permissionsEnabled: true

If after this you disable access management (permissionsEnabled: false), all users who open the Deckhouse Commander interface will regain full rights.

Assigning Temporary Administrators for Access Management Setup

Attention! This step can be skipped if before upgrading to version 1.11 you have logged in to Deckhouse Commander at least once with your account.

For initial setup, or in cases where admin privileges are lost, you can assign temporary administrators.

Create a ConfigMap commander-admins in the d8-commander namespace, specifying users and groups requiring temporary admin access:

apiVersion: v1
kind: ConfigMap
metadata:
  name: commander-admins
  namespace: d8-commander
data:
  users: |
    john.doe@example.com
    jane.doe@example.com
  groups: |
    Enterprise Admins
    Administrators

Users and group members listed above will receive full rights in the Deckhouse Commander interface. After this, you can proceed to configure access permissions via the web interface.

Attention! After finishing the necessary roles and bindings setup, delete the commander-admins ConfigMap, global role autogenerated-commander-admin and role binding autogenerated-commander-admins. Temporary access will then be revoked, and only manually assigned privileges will apply.

Configuring Access Permissions in Deckhouse Commander Web Interface

Before proceeding, ensure RBAC support is enabled in the current Deckhouse Commander installation and you are logged in as an administrator. To configure permissions, follow these steps:

1. Open the permissions settings panel.
2. Go to the “Roles” tab and create a role:
   1. Click the “Add Global Role” button.
   2. Specify the unique role name and description.
   3. Click “Add Commander Rule”.
   4. Specify permissions and resources.
   5. Optionally create multiple rules.
   6. Click “Save”.
3. Go to the “Bindings” tab and create a binding:
   1. Click the “Add Global Binding” button.
   2. Specify a name or enable the “Generate from role” toggle (which generates a name from the role plus a random string).
   3. Select a role.
   4. Select users or groups. If a user or group does not exist in Deckhouse Commander yet, you can specify them manually as user:<login> / group:<name>.
   5. Click “Save”.

Permissions have been applied.

Audit

All role and binding changes are logged. Information is available in the “Change History” tab at the workspace level.