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:

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

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

Space resources

Short Example

In this 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.

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 .

2. Click the Add User button.

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.

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”.

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.

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

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

1. Click the 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.

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

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.

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.

   

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:

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

Changes in RBAC and User Sessions

You should consider 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.

See Also

• This documentation:
  • Search for “rbac” to find more information about managing access wrights via user roles in Kublr, like:
  • RBAC Example: Access to Business Application and OS Logs Only