Kublr RBAC

Role-based access control (RBAC) is an approach that restricts system access to resources based on user roles.

Overview

Leveraging Kublr RBAC capabilities, an administrator can create roles that prevent users from accessing specific resources. For example, a role can be created that allows a user to view and update clusters, but does not allow deleting them. Roles can be created in global scope (affect all spaces) or space scope (affect a specific space in which it is created).

Main Entities

By default EVERYTHING is DENIED, RBAC entities are used only to ALLOW specifiс actions.

Thus when reading the description below, any conflicts are resolved by combining ALLOW rules.

The main entities of Kublr RBAC are:

  • Space
  • Role
    • Global Role
    • Space Role
  • Rule
  • Resource
  • User
  • Group
  • Role Binding
    • Global Role Binding
    • Space Role Binding

Space is an isolated area of the Kublr system where objects (clusters, credentials etc.) are stored separately, so the things do not mix up. Spaces may be used to separate objects created by different users, for different purposes, with different priority (prod, qa, dev), etc.

Role describes a set of permissions in the system. For example, this can be “Administrator” or “Read Only User” or “Superman”. A role by itself does not specify users or groups to which it will be later bound (via Role Bindings). There are:

  • Global Role (Space set to “All Spaces”) defines access to global (non-space) and space resources. Can be later bound to Users/Groups by:

    • Global Role Binding (Space set to “All Spaces”) - that will affect access to global resources and space resources in all spaces.
    • Space Role Binding (Space set to some space) - that will affect access to that space resources.
  • Space Role (Space set to some space) defines access to space resources. Can be later bound to Users/Groups only by the Space Role Binding of the same space.

    For details on different role types and examples, refer to Kubernetes documentation, Using RBAC Authorization aticle.

A role is a set of Rules.

Each Rule takes one or several Resources and says what is ALLOWED for them.

The table below describes the list of permissions:

VerbsSynonymsMeaning
All ActionsAll Actions-
ListListSee the object name in lists or menus where it is presented.
GetReadOpen the object page and see its content, parameters.
PostCreateCreate an object of this type.
PutUpdateChange the object content, parameters.
DeleteDeleteDelete the object.

Resource is what is presented within Kublr. There are:

  • Global Resource is anything beyond the Space and the spaces themselves.
  • Space Resource is anything within the Space, first of all, clusters and different UI sections representing information about them.

See resources list and description in the sections below: Global Resources and Space Resources.

User is an account to log into the Kublr. A user can belong to one or several Groups. Managed via Keycloak administrative interface.

Group is a bunch of Users. Managed via Keycloak administrative interface.

Global Resources

ResourceDescription
globalroleSecurity > Roles > Global Role
Standard CRUD** rights check.
globalrolebindingSecurity > Roles > Global Role Binding
Standard CRUD rights check.
spaceSpace
Standard CRUD rights check.
kcpconfigSettings (left menu)
Standard CRUD rights check.

** CRUD - in IT, create, read, update, and delete (CRUD) are the four basic data operations.

Space Resources

ResourceDescription
clusterCluster Specification

GET:
- Cluster List Page - Open Cluster (also requires cluster/id)

POST:
- Cluster List Page - Add Cluster

PUT:
- Edit Cluster Page - Save Changes
- Edit Cluster Page (onprem)
- Delete Instances Group
- Cluster Specification Page - Create Cluster
- View Cluster Page - Rollback Cluster

DELETE:
- Edit Cluster Page - Delete Cluster
- View Cluster Page - Delete Cluster
cluster/idCluster Specification by ID

GET:
- Cluster List Page - Open Cluster (works with cluster)
cluster/applicationsCluster page > Applications tab
cluster/metricsCluster metrics
cluster/registerDeprecated: Not used
cluster/deregisterDeprecated: Not used
cluster/configKubernetes Config

GET:
- View Cluster Page - Download Kube Config File
cluster/admin-configKubernetes Config with administrative permissions

GET:
- View Cluster Page - Download Kube Config File
cluster/proxyProxies’ requests to cluster

GET:
- View Cluster Page - Dashboard Link
cluster/admin-proxyProxies’ requests to cluster with administrative permissions

GET:
- View Cluster Page - Dashboard Link
cluster/dashboardKubernetes Dashboard

GET:
- View Cluster Page - Dashboard Link
cluster/admin-dashboardKubernetes Dashboard with administrative permissions

GET:
- View Cluster Page - Dashboard Link
cluster/terminalTerminal with different tools (kubectl, helm, curl, net-tools …)

GET:
- View Cluster Page - Open Web Console
cluster/admin-terminalTerminal with different tools with administrative permissions

GET:
- View Cluster Page - Open Web Console
secretCredentials (left menu)
Standard CRUD rights check.
secret/testTest current credentials

LIST:
- Secret List Page - Test Credentials Button
backupBackup Specification
Standard CRUD rights check.
backupconfigurationBackup Config Specification
Standard CRUD rights check.
eventCluster page > Events tab
spaceroleSecurity > Roles > Space Role
Standard CRUD rights check.
spacerolebingingSecurity > Roles > Space Role Binding
Standard CRUD rights check.
spaceThe name of space for resources
Standard CRUD rights check.

Short Example

In this example:

RBAC Example

…global role allowing to see spaces and clusters in the lists and open their pages is bound with the user “jsmith-junior” via the space role binding related to “jsmith” space. This will lead to the user “jsmith-junior” being able to see only the “jsmith” space in the spaces menu. Within this space the user will be able to see the list of clusters and open the page of each cluster to view information about it.

Step-by-Step Example

In this example we will configure a security so that in Kublr, the user “bob” will be able to log in and view the “new-space” space.

Keycloak

Keycloak provides administrators with control over the users. To access the Keycloak administrative screen of your Kublr:

  • In adress bar, add the “auth” to your Kublr URL, like “https://YourKublr.com/auth”.
  • Alternatively, you can open any existing platform and follow the Keycloak link. Open Keycloak Screen

 
Keycloak Start Page

Then click Administration Console and provide your Keycloak credentials.

Using Keycloak, an administrator can create new users and assign them into groups. Kublr creates two user groups for you: KublrDefaultUser and KublrFullAdmin. By default, every new user (not admin) is assigned to a group KublrDefaultUser. This means that every new user has a certain set of permissions assigned by default. User groups help put multiple users in the same category. An administrator is able to create more user groups if required.

Using the user groups and Kublr RBAC an administrator is able to link restrictions to a group of users. For more information about groups in Keycloak, click here.

To create a new user:

  1. In Keycloak, on the left menu, click Keycloak Users Button.

  2. Click the Add User button. Keycloak Add User

  3. Fill out the form and click Save to create a new user.

  4. After the user is created you can view the groups the user is assigned to by navigating to Groups tab. Keycloak User Groups

  5. On to the Credentials tab, set password. Write it down to use later with the “bob” user.

  6. Turn off the Temporary option.

  7. Click Save Password.

Spaces

Add a space:

  1. In Kublr, on the left menu, click Security. The SECURITY page is displayed.

  2. Use the Spaces tab.

  3. Click CREATE SPACE. The Create Space dialog is dislayed.

  4. In the Create Space dialog, set Space Name to “new-space”. Creating Space

  5. Click CREATE.

    The SECURITY page, its SPACES tab, is displayed. The new space is added to the list and automatically selected to be displayed in the system. List of Spaces

Roles

In Kublr, on the Security page, the Roles tab, an administrator is able to view global roles and space roles. By default Kublr creates a standard set of roles for you. Those roles are:

  • KublrFullAdmin
  • KublrDefaultUser
  • KublrReadOnlyUser
  • KublrAnonymousUsers
  • KublrAuthenticatedUsers

Admin’s Roles Screen

Let’s create a global role which will allow viewing clusters in spaces.

  1. Click the Add New Role Button button. The Add New Role dialog is displayed.

  2. In the Add New Role dialog, set:

    • Name to “my-new-role”.
    • Space to “All spaces”.
  3. Click ADD NEW RULE. The Add New Rule dialog is displayed.

  4. In the Add New Rule dialog, from the Resources list, select:

    • “Global Resources > space”
    • “Space Resources > cluster”
    • “Space Resources > cluster/id”

    Now we will specify the Verbs which define what kind of permissions you would like to provide for the selected resources. In our case, let’s only provide an ability to view the clusters within spaces but not to update or delete them.

  5. In Verbs, select List and Get. Add New Rule

  6. Click CREATE. The Add New Rule dialog is closed. In the Rules section, the new rule is displayed. Add New Rule

  7. In Add New Role dialog, click SAVE ROLE. The SECURITY page, its ROLES tab, is displayed. The new rule is added to the list.

Now that the role is created, we need to bind the user called bob with that role. This can be accomplished by using Role Bindings.

Role Bindings

Now we will bind the “bob” user to the previously created “my-new-role” role and in the same time limit this role scope to the only space: “new-space”.

  1. Make sure, you are at the SECURITY page.

  2. Use the ROLE BINDINGS tab.

  3. Click ADD NEW ROLE BINDING. The Add New Role Binging dialog is displayed.

  4. In the Add New Role Binging dialog, set:

    • Name to “my-new-role-binding”.
    • Space to “new-space”.
    • Role to previously created “my-new-role”.
  5. Click ADD NEW SUBJECT. The Add new subject dialog is displayed.

  6. In the Add new subject dialog, set:

    • Kind to “User”.
    • Name to “bob”.
  7. Click SAVE SUBJECT. The Add New Role Binging dialog is displayed again with the new user added to the Subjects section. Add New Role Binding

  8. Click SAVE ROLE BINDING.

    The SECURITY page, its ROLE BINDINGS tab, is displayed. The new binding is added to the list.

Check Result

To check the result:

  1. Login under “bob” with your previously written down password.

  2. On the top bar, from the list of spaces, select “new-space”.

  3. On the left menu, click Clusters.

    User Screen

Additional configuration

You can perform additional rule configuration (at Security > Roles > some role > existing or new rule) using the following fields:

  • Resource Names - an optional whitelist of names to which the rule applies. For example, these are names of allowed clusters if the “cluster” resource was selected. An empty set means that everything is allowed.

  • Non-resource URL - Set of partial urls that a user should have access to. *s are allowed, but only as the full, final step in the path.

    Notes

    • Since non-resource URLs are not namespaced, this field is only applicable for Global Roles and will only work with Global Role Bindings.
    • Rules can either apply to API resources (such as “clusters” or “secrets”) or non-resource URL paths (such as “/metrics”), but not both.

Examples

In this example, for the user/group bound to the role with this rule only cluster-001, cluster-002 and cluster-003 clusters will be available:

desc

And this configuration provides the user/group bound to the role with this rule with the list and get permissions for the /metrics URL:

desc

Changes in RBAC and user sessions

You should concider that if you change something for a user (password, group membership, binding to a role, rules in currently bound roles) and this user has an active session (logged into Kublr), the new settings will only be applied after user’s re-logon into the system.