Kasten RBAC Multi-Tenant Multi-Cluster Keycloak - 1

In this post we will look at configuring Role Based Access Control (RBAC) together with Kasten K10 to control access to one or more clusters protected by Kasten. It is aimed both at customers who run one or more clusters on any Kubernetes distribution supported by K10, and at service providers (SP or MSP) that offer Kubernetes container backup with Kasten K10, with the goal of providing controlled access to users and customers according to the granular roles required for each cluster or operation. We will also use a Single Sign-On (SSO) solution based on OpenID, in this case Keycloak, for centralized management of access credentials for both users and groups.

Initial Steps

#

The idea behind this series is to explain how to create the groups, roles, clusterroles and other RBAC-related resources without having to keep modifying the Kubernetes cluster directly over time, so that all user creation, group management and group assignment is handled in Keycloak.

As always on this blog, we should refer to the official documentation for whatever we are about to install, configure or apply, since we want to stay as close as possible to the best practices and guidelines set by the creators of the solutions we will use.

Keycloak https://www.keycloak.org/documentation

Kasten K10 https://docs.kasten.io/latest/

RBAC Kasten K10 https://docs.kasten.io/latest/access/rbac.html

RBAC Kasten K10 Multi-Cluster Manager https://docs.kasten.io/latest/multicluster/rbac.html

Installing K10 and Multi-Cluster

#

We will not go deep into installing the products in this post, since the following links walk you step by step through installing Kasten K10 and the Kasten Multi-Cluster Manager:

Kasten K10 /veeam-kasten/

Kasten K10 Multi-Cluster Manager /instalar-kasten-multi-cluster-manager/

As for installing Keycloak, it is very simple via Helm, or you can follow one of the many guides on the internet to install it as a container or as an application on a server. (Leave a comment if you need a step-by-step guide.)

Let’s now go over a summary of the existing roles and clusterroles used to build granular permissions.

Kasten K10 RBAC

#

When we review the documentation, we see that there is RBAC for a standalone installation of Kasten K10, following Kubernetes standards, as well as RBAC for multi-cluster installations using the Multi-Cluster Manager.

In this case we will look at applying Roles, RoleBindings, ClusterRoles and ClusterRoleBindings to Kasten K10 to obtain granular access to our K10 deployment based on operational needs. Reviewing the documentation, we find the default ClusterRoles that are created when K10 is installed, of which there are 3:

• k10-admin / Full access to the Kasten K10 deployment
• k10-basic / Operational access for users on specific resources
• k10-config-view / Access to configuration without permission to create or modify

You can list them with the following command:

kubectl get clusterrole | grep k10

```bash




        
          
          
        
  
  
  

In fact, if you review the permissions in detail by inspecting each clusterrole, for example:

```bash
kubectl describe clusterrole k10-admin

```bash




        
          
          
        
  
  
  

You can see all the permissions, resources and verbs (what each one can do) for every clusterrole, which form the basis for building granular access permissions to K10. You can use them as a starting point to later create ClusterRoleBindings tied to users or user groups that will authenticate via OpenID.

Another important role that also exists within the K10 installation is **k10-ns-admin**, which grants access to secrets and lets you view service status directly from the K10 console. To list the role, you must include the **kasten-io** namespace:

```bash
kubectl get roles -n kasten-io

```bash




        
          
          
        
  
  
  

## K10 Multi-Cluster Manager RBAC

As with the above, when you configure the K10 Multi-Cluster Manager from the primary cluster, 2 clusterroles are created by default, along with K10-specific clusterroles:

- k10-mc-admin / Grants full access to manage multiple clusters and resources
- k10-mc-user / Grants access to the cluster but not to management resources

```bash
kubectl get clusterrole | grep k10-mc

```bash




        
          
          
        
  
  
  

K10-specific clusterroles for managing RBAC within K10 Multi-Cluster:

- k10-multi-cluster-admin / Grants full access to manage multiple clusters and resources
- k10-multi-cluster-basic / Grants access to the cluster but not to management resources
- k10-multi-cluster-config-view / Grants access to the cluster and to the configuration view

```bash
kubectl get k10clusterrole -n kasten-io-mc

Why are there two types of clusterroles? The first roles are associated with Kubernetes resources and clusters, while the k10clusterroles are tied to the internal management of the Multi-Cluster Manager, with the aim of providing access via RBAC within K10.

In this guide we will configure specific clusterroles and roles according to the access and operational needs, using the resources Kasten K10 provides, but first let’s move on to configuring Keycloak.

Keycloak Configuration

#

After installing Keycloak, you can access the “master” domain or realm through the web with the user you configured. For example, in my case I use auth.24xsiempre.com and log in to the administration console:

You can keep the default settings, or at least enable brute force detection in the “Security Defenses” menu.

Now we will create a new realm dedicated to Kasten K10. To do so, we select the “master” realm in the main menu, click on “Add Realm”, enter the name of the new realm, and finally click “create”:

Within “Realm Settings” there are several options, as shown in the Keycloak menu. In this case we will enable brute force detection in “Security Defenses” (optional, but recommended) and, most importantly, the following options in the “Login” menu:

It is best to use these options. For “Forgot password” and “Verify Email” to work, you need SMTP configured in Keycloak, where it is very easy to enter the address, username and password of the SMTP server in the “Email” menu.

Keycloak Client Configuration

#

We now have the Keycloak basics in place, so let’s dive into configuring a client in Keycloak to use OpenID together with K10. Click on “Clients” and then on “Create” to enter the name of the “Client ID” (in this case kasten), making sure the “Client Protocol” is “openid-connect”:

Then open the new client from the “Clients” menu.

Now we will configure the client in detail so that it uses OpenID and allows access to users or groups. The settings to apply are the following:

Next I will explain each of the configured fields:

• Enabled = Enables the Keycloak client
• Always Display in Console = Lets you see sessions in the Keycloak console
• Login Theme = The graphical interface style
• Client Protocol = Enables the openid-connect protocol we will use with K10
• Access Type = Requires a credential to use the Keycloak client
• Standard Flow Enabled = Enables OpenID redirects for authentication and authorization
• Direct Access Grants Enabled = Username and password access, exchanged with Keycloak
• Service Accounts Enabled = In case you use service accounts
• OAuth 2.0 Device Authorization Grant Enabled = OAuth 2.0 support
• Authorization Enabled = Enables granular authorization
• Valid Redirect URIs = The valid URIs used to sign in to and out of the application
• Web Origins = CORS origins configuration
• Backchannel Logout URL = The client’s logout URL
• Backchannel Logout Session Required = Whether the session id must be included in the logout
• Backchannel Logout Revoke Offline Sessions = Revokes offline access
• Browser Flow = Will use browser-based authentication
• Direct Grant Flow = Will issue the session directly

Now we will add a role so that it is associated with K10. Go to “Roles” within the same “Client” we just configured and add a new role named “k10”:

Now open the newly created role, go to “Composite Roles”, click on “Client Roles”, select “kasten”, and assign the new “k10” role under “Associated Roles”:

And finally we will set the new role as a default. Click on “Roles” and then on the “Default Roles” menu, select “kasten” under “Client Roles”, and add the new “k10” role to the default roles:

Keycloak Groups Configuration

#

By default, Keycloak does not have groups configured in “Client Scopes”. This means that if we set up authentication tied to groups, it will not work, since Kasten or the application will not be able to read the groups created in Keycloak. So we click on “Client Scopes”, then on “Create”, enter the name “groups”, make sure the protocol is “openid-connect”, and save:

We open the newly created “groups” Client Scope and then click on “Mappers” to create a new mapping. Click on “Create”, enter the name “groups”, select the “Mapper Type”, which should be “Group Membership”, enter “groups” in “Token Claim Name”, turn off “Full group path”, leave the other options enabled, and save:

Then we click on “Scope”, select the “Client Roles”, which is “kasten”, to add the assigned “k10” role:

And finally we need to add the new “Client Scope” as a default so that Kasten can read it. Under “Client Scopes”, select the “Default Client Scopes” menu and move “groups” to the default assigned scopes:

Creating Groups in Keycloak

#

An excellent way to manage users is to associate them with groups that already carry the required permissions or roles, making their administration much faster. As a best practice, use the same naming convention as Kasten when creating groups. Click on “Groups” and then on “New” to enter the group name, for example “k10:admins”, and save.

Then we select and edit the group to open the “Role Mappings” menu, and under “Client Roles” we select “kasten” and assign the “k10” role, as we can see in the following image:

You can create as many groups as needed and assign the role above to each of them, just as we did here.

Creating Users in Keycloak

#

Now we will create an administration user to manage Kasten K10, whether on a single cluster or using the Multi-Cluster Manager. To do so, we go to the “Users” menu and enter the required information and the associated group, in this case “k10:admins”. Remember that for email verification you must have the SMTP server configured. Otherwise, you simply enable it:

One important point: optionally, you can ask the customer to configure MFA for better security by adding it under “Required User Action”. Now we will assign a password to the user. Click on “Credentials”, enter the required “password”, turn off the “Temporary” option, and click “Set Password”:

We are now ready to start setting up Kasten K10 authentication with Keycloak. In the next post (Click Here) we will go through it step by step.

Frequently asked questions

#

Related posts

#

• Kasten RBAC Multi-Tenant Multi-Cluster Keycloak - 2
• Kasten RBAC Multi-Tenant Multi-Cluster Keycloak - 3
• Kasten K10 Authentik
• How to Integrate Active Directory with Kasten K10 and OpenShift
• Chile Law 21.719: technical compliance manual with Veeam