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
• projects — Projects
• projectrolebindings — Project member bindings
• billingdashboard — Billing: dashboard and analytics
• billingtariffs — Billing: tariff management
• billingresources — Billing: management of compute classes and storage classes
• billingreports — Billing: reports management

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
• projects/audit — Projects 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 workspace.

Configuration

Requirements for Access Management in Deckhouse Commander

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

For access to application clusters, Commander reuses the same identity — see Authentication in application clusters via DexProvider for how the trust link is established and which resources are managed automatically.

Assigning Temporary Administrators for Access Management Setup

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

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.

Project Access Management

Access management in Deckhouse Commander projects is organised on two levels:

1. Global Commander roles define permissions over projects as Commander resources: access to the “Projects” section, creating, updating, and deleting projects, managing project members.
2. Project-level roles define permissions over project resources in the target cluster. Bindings are translated into the AuthorizationRule manifest, which is applied in the cluster by the multitenancy-manager module as part of project resources.

Commander Resources for Managing Projects

The following entries are part of the list of supported resources:

• projects — projects.
• projectrolebindings — project member bindings. Access to managing projectrolebindings of a specific project is checked against the user’s membership in the Admin role of that project, not only against the global role.

The “Projects” section is shown in the web interface only to users who have at least the get verb on the projects resource and only when the projects feature is enabled in Deckhouse Commander.

Preset Global Roles

Deckhouse Commander ships two preset global roles for working with projects:

• autogenerated-projects-user — a role with the rule verbs: ["get"], resources: ["projects"]. Automatically granted to a user added to at least one project via the single workspace-level binding autogenerated-projects-users. It grants access to the “Projects” section and to project pages, but does not allow creating, updating, or deleting projects, nor managing members of projects where the user is not an Admin. The role and its binding are enforced by Deckhouse Commander: if deleted manually, they are recreated the next time a user is added to any project.
• projects-admin — a role with the rule verbs: ["*"], resources: ["projects"]. Intended for users who create, update, and delete projects. Assigned manually by a system administrator in the “Users and Permissions” section.

For finer-grained control, a system administrator can create custom global roles with arbitrary combinations of verbs on the projects and projectrolebindings resources.

Project Visibility in the List

The set of projects visible to a user in the list is determined by their permissions on the projects resource:

Project-Level Roles

Each project exposes four preset roles. Their names in Commander match the spec.accessLevel values in the AuthorizationRule manifest that Commander generates for each role:

The set of Kubernetes resources and actions corresponding to each accessLevel is defined by the user-authz module.

For each project-level role, Commander creates a dedicated AuthorizationRule in the target cluster (admins, editors, privileged-users, users). Members are listed in spec.subjects[]. Manifests are delivered by the Deckhouse Commander agent.

Separation of Duties

• System administrator manages project settings on the “Configuration” tab of the project page, including the “Administrators” field.
• Project administrator (a user in the Admin role) manages User, PrivilegedUser, and Editor bindings on the “Accesses” tab of the project page. Admin bindings are shown on that tab in read-only mode and are changed on the “Configuration” tab.
• Users in the Editor, PrivilegedUser, or User role do not see the “Accesses” tab.

If one user combines both functions (for example, a system administrator is also assigned as Admin of a project), both tabs are available in the interface.

Maintenance of the autogenerated-projects-users Binding

When a user is added to any project, Deckhouse Commander adds them as a subject of the single workspace-level binding autogenerated-projects-users. One such binding is created per workspace and aggregates members of all projects of that workspace.

When a user is removed from a project, their subject is not removed from autogenerated-projects-users automatically, so that users who remain members of other projects do not lose access. If needed, a system administrator can remove the subject manually in the “Users and Permissions” section. If the autogenerated-projects-users binding is deleted entirely, it is recreated the next time a user is added to any project of the workspace.

Validation

• A project must have at least one administrator (the Admin role): the last Admin binding cannot be removed.
• If a user is a member through multiple paths (several groups, or a group and a direct assignment), the effective permissions in the cluster are determined by the user-authz module by priority: Admin > Editor > PrivilegedUser > User.

Limitations

• Projects of kind deckhouse are DKP projects created directly in the target cluster and not managed by Deckhouse Commander. They appear in the project list with a dedicated icon. For such projects, the Deckhouse Commander web interface does not provide an edit form or an “Accesses” tab — these projects are managed directly in Deckhouse using the multitenancy-manager module, including through the AuthorizationRule manifest.
• In this version, project membership and the preset roles (autogenerated-projects-user, projects-admin) can be managed only through the Deckhouse Commander web interface.

Audit

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