RBAC Example: Groups with Different Access Levels

This article provides detailed example of the implementation of role-based access control (RBAC) in Kublr environments with multiple Kubernetes clusters. It explores the challenges and benefits of managing access control in distributed environments and introduces a comprehensive RBAC matrix to govern different roles based on user permissions across multiple separated clusters. The article emphasizes the significance of RBAC in enhancing security and maintaining fine-grained control over resources within the Kublr ecosystem.

RBAC Model

The example covers the following RBAC model:

• clusters in the develop and prod spaces - one in each
• users:
  • developer user has access to development cluster only - cluster in develop space, can read only business application logs. Also It has access to Kubernetes namespace develop with Kubernetes role “admin”.
  • prod-operation user has access into production cluster (prod space), can read only business application logs, can restart pods in Kubernetes “prod” namespace in production cluster.
  • kublr-administrator user can create/modify/delete clusters in any of two namespaces, but it can’t access to static admin resources (Kubernetes objects inside clusters)
  • cluster-administrator user has access into development and production clusters with non static admin resources access, can modify cluster configuration on KCP, read logs and metrics but it can’t access to static admin configuration. Also this user can’t create new cluster in KCP or remove existing cluster.

A RBAC configuration is implemented on 3 levels:

• Kublr Control Platform
• Kubernetes cluster
• Logging (Supported by SearchGuard)

As we have Keycloak as a main authentication provider, the users and groups are created there. Using groups for user access right management in any system provides a more efficient, organized, and secure approach to RBAC administration, empowering organizations to maintain better control over their cluster resources and access policies.

in Keycloak, the following groups should be presented to manage users:

• Developers
• ProdOperations
• KublrAdministrators
• ClusterAdministrators

Procedure

Configuring groups and users (in Keycloak)

1. Select the kublr-ui realm.
2. In Groups, create the Developers, ProdOperations, KublrAdministrators, and ClusterAdministrators groups.
3. In Users:
4. Create developer user and add one to the KublrReadOnlyUsers and Developers groups.
5. Create prod-operation user and add one to the KublrReadOnlyUsers and ProdOperations groups.
6. Create kublr-administrator user and add one to the KublrReadOnlyUsers and KublrAdministrators groups.
7. Create cluster-administrator user and add one to the KublrReadOnlyUsers and ClusterAdministrators groups.

Creating spaces and clusters (in Kublr)

1. In Security → Spaces tab, create develop and prod spaces.
2. In Clusters, create 1 cluster in each of these spaces.

Schema

In this example the following configuration will be performed:

See details in the sections below.

Enabling general access to spaces (in Kublr)

In Kublr, the role that will allow access to spaces in general is required. All user groups should be bond to it to operate in Kublr UI.

1. In Security → Roles, create the AllSpacesViewer global role: rule for space, Verbs - “list”

   

2. In Security → Role Bindings, create the AllSpacesView-role-binding role binding: bind the AllSpacesViewer role to all for created groups.

Configuring access for Developers group

1. In Security → Roles, create the developer-role global role: rule for space, cluster, cluster/id, cluster/proxy, cluster/dashboard, cluster/config, cluster/terminal, Verbs - “list”, “get”.

2. In Role Bindings, create the developer-role-binding role binding: bind the developer-role role the Developers group.

3. Access the kubectl tool for your cluster in the develop space, execute:

   kubectl create namespace develop
   

4. In Kublr UI, access your develop space cluster page → ADMINISTRATION tab.

5. In Role Bindings, create the developer-access role binding: for namespace develop bind the admin role the Developers group.

Configuring access for ProdOperations group

1. In Security → Roles, create the ProdOperations-role global role: rule for space, cluster, cluster/id, cluster/proxy, cluster/dashboard, cluster/config, cluster/terminal, Verbs - “list”, “get”.

2. In Role Bindings, create the ProdOperations-role-binding role binding: bind the ProdOperations-role role the ProdOperations group.

3. Access the kubectl tool for your cluster in the prod space, execute:

   kubectl create namespace prod
   

4. In Kublr UI, access your prod space cluster page → ADMINISTRATION tab.

5. In Roles, create the ProdOperations-cluster-role role: for namespace prod, add new rule for Resources - “pods”, Verbs - “delete”, “get”, “list”

6. In Role Bindings, create the ProdOperations-cluster-role-binding role binding: for namespace prod bind the ProdOperations-cluster-role role the ProdOperations group.

Configuring access for KublrAdministrators group

1. In Security → Roles, create the KublrAdministrators-role global role:

   • rule for cluster, cluster/id, cluster/proxy, Verbs - “*”
   • rule for space, Verbs - “list”, “get”
   • rule for secret, Verbs - “*”

2. In Role Bindings, create the KublrAdministrators-prod-role-binding role binding: for space prod, bind the KublrAdministrators-role role the KublrAdministrators group.

Configuring access for ClusterAdministrators group

1. In Security → Roles, create the ClusterAdministrators-role global role:

   • rule for space, Verbs - “list”, “get”
   • rule for cluster, cluster/id, Verbs - “list”, “get”, “put”
   • cluster/applications, cluster/proxy, cluster/metrics, Verbs - “*”
   • rule for secret, Verbs - “list”

2. In Role Bindings, create the ClusterAdministrators-prod-role-binding role binding: for space prod, bind the ClusterAdministrators-role role the ClusterAdministrators group.

Configuring roles for Search Guard (in Keycloak)

1. Select the kublr-ui realm.

2. In Realm roles, create the following realm roles:

   • sg_allow_cluster_administrator
   • sg_develop_allow_only_app_logs
   • sg_prod_allow_only_app_logs

3. In Groups:

   • Assign sg_allow_cluster_administrator realm role to the ClusterAdministrators group
   • Assign sg_develop_allow_only_app_logs to the Developers group
   • Assign sg_prod_allow_only_app_logs to the ProdOperations group

Configuring Search Guard on ELK in Kubernetes cluster

1. Login to the cluster with administration config.

2. Enter logging-controller pod:

   kubectl exec -it -n kublr $(kubectl get pods -n kublr \
           -o=custom-columns=NAME:.metadata.name | grep logging-controller) /bin/bash
   

3. Use the following command to retrieve current SG configuration:

   bash-4.4$ cd /tmp
   bash-4.4$ /opt/logging-controller/sg_retrieve.sh
   bash-4.4$ ls
   sg_action_groups.yml   sg_config.yml  sg_internal_users.yml  sg_roles.yml  sg_roles_mapping.yml
   

4. Add the following lines to the end of roles.yaml:

   sg_prod_allow_only_app_logs:
       index_permissions:
       - allowed_actions:
           - "SGS_READ"
           index_patterns:
           - "kublr_prod*"
   sg_develop_allow_only_app_logs:
       index_permissions:
       - allowed_actions:
           - "SGS_READ"
           index_patterns:
           - "kublr_develop_*"
   sg_allow_cluster_administrator:
       index_permissions:
       - allowed_actions:
           - "SGS_READ"
           index_patterns:
           - "kublr_develop_*"
           - "kublr_kublr*"
           - "kublr_prod*"
   

5. Add the following lines to roles_mapping.yaml:

   sg_prod_allow_only_app_logs:
       backend_roles:
       - "sg_prod_allow_only_app_logs"
   sg_develop_allow_only_app_logs:
       backend_roles:
       - "sg_develop_allow_only_app_logs"
   sg_allow_cluster_administrator:
       backend_roles:
       - "sg_allow_cluster_administrator"
   

6. Apply configuration changes to Search Guard:

   bash-4.4$ /opt/logging-controller/sg_apply.sh
   

See Also

• This documentation:
  • Search for “rbac” to find more information about managing access wrights via user roles in Kublr, like:
  • Kublr RBAC (role-based access control)