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.
The example covers the following RBAC model:
develop
and prod
spaces - one in eachdeveloper
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:
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
kublr-ui
realm.Developers
, ProdOperations
, KublrAdministrators
, and ClusterAdministrators
groups.developer
user and add one to the KublrReadOnlyUsers
and Developers
groups.prod-operation
user and add one to the KublrReadOnlyUsers
and ProdOperations
groups.kublr-administrator
user and add one to the KublrReadOnlyUsers
and KublrAdministrators
groups.cluster-administrator
user and add one to the KublrReadOnlyUsers
and ClusterAdministrators` groups.develop
and prod
spaces.In this example the following configuration will be performed:
See details in the sections below.
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.
In Security → Roles, create the AllSpacesViewer
global role: rule for space
, Verbs - “list”
In Security → Role Bindings, create the AllSpacesView-role-binding
role binding: bind the AllSpacesViewer
role to all for created groups.
Developers
groupIn 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”.
In Role Bindings, create the developer-role-binding
role binding: bind the developer-role
role the Developers
group.
Access the kubectl tool for your cluster in the develop
space, execute:
kubectl create namespace develop
In Kublr UI, access your develop
space cluster page → ADMINISTRATION tab.
In Role Bindings, create the developer-access
role binding: for namespace develop
bind the admin
role the Developers
group.
ProdOperations
groupIn 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”.
In Role Bindings, create the ProdOperations-role-binding
role binding: bind the ProdOperations-role
role the ProdOperations
group.
Access the kubectl tool for your cluster in the prod
space, execute:
kubectl create namespace develop
In Kublr UI, access your prod
space cluster page → ADMINISTRATION tab.
In Role Bindings, create the ProdOperations-cluster-role-binding
role binding: for namespace prod
bind the ProdOperations-role
role the ProdOperations
group.
KublrAdministrators
groupIn Security → Roles, create the KublrAdministrators-role
global role:
cluster
, cluster/id
, cluster/proxy
, Verbs - “*”space
, Verbs - “list”, “get”secret
, Verbs - “*”In Role Bindings, create the KublrAdministrators-prod-role-binding
role binding: for space prod
, bind the KublrAdministrators-role
role the KublrAdministrators
group.
ClusterAdministrators
groupIn Security → Roles, create the ClusterAdministrators-role
global role:
space
, Verbs - “list”, “get”cluster
, cluster/id
, Verbs - “list”, “get”, “put”cluster/applications
, cluster/proxy
, cluster/metrics
, Verbs - “*”secret
, Verbs - “list”In Role Bindings, create the ClusterAdministrators-prod-role-binding
role binding: for space prod
, bind the ClusterAdministrators-role
role the ClusterAdministrators
group.
Select the kublr-ui
realm.
In Realm roles, create the following realm roles:
sg_allow_cluster_administrator
sg_develop_allow_only_app_logs
sg_prod_allow_only_app_logs
In Groups:
sg_allow_cluster_administrator
realm role to the ClusterAdministrators
groupsg_develop_allow_only_app_logs
to the Developers
groupsg_prod_allow_only_app_logs
to the ProdOperations
groupLogin to the cluster with administration config.
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
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
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*"
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"
Apply configuration changes to Search Guard:
bash-4.4$ /opt/logging-controller/sg_apply.sh