Managing Users and Authorizations in Kyma

Kyma security is built on Kubernetes robust Role-Based Access Control (RBAC) system, which ensures that users and services have the necessary permissions to perform actions without compromising the platform's security. Through precise role assignments and API definitions, Kyma allows fine-grained access control over resources. The RBAC concept includes the use of roles and role bindings, cluster roles and cluster role bindings, and the definition of these roles based on API Groups and Verbs. The RBAC concept is completely decoupled and independent from the concept of roles and role collections on the account level of SAP BTP.

You can learn more about RBAC here: Using RBAC Authorization

If you're a more technical person like an administrator or a developer, you need to interact with the underlying cluster of Kyma. To do so, you need to log on to the Kyma dashboard. In order to log on to this dashboard, your user must be added to the Kyma environment. Users are still stored in identity providers and just linked to the Kyma environment. After you get the correct roles or cluster roles bound to your user through a role binding in RBAC, you are able to interact with attributes, objects, and elements from or executed in the underlying cluster.

If you are more of an end user or, as we call them on account level of SAP BTP, a business user, you interact with services and applications deployed and running in the Kyma environment. If the developers followed the recommendations making use of the XSUAA service, granting authorizations is done through roles and role collections on Subaccount level via the SAP BTP cockpit. For this scenario, everything can be used as you already learned in previous lessons.

When you want to assign authorizations to users inside of Kyma, you need to work with roles and cluster roles. Both are quite similar but have small differences in detail.

When creating cluster roles, you need to define rules and, optionally, labels and annotations. With these elements, you define the structure and authorizations the receiver of the role gets granted.

Here's an example of a cluster role with full access to everything (not recommended):

12345678
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

Here's an example of a role with authorizations for managing pods and services in a namespace called my-namespace:

123456789
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: my-namespace
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "create", "delete"]

You want to determine the already created and existing cluster roles in your Kyma environment. To do so, you need to navigate to the Kyma dashboard and using the sidebar menu: Configuration → Cluster Roles. You can see all the existing cluster roles and select them to get the role details displayed. If you need to change an existing role, you simply choose Edit. If you want to determine or change a Role instead of a Cluster Role, the process is identical, except you need to first enter the corresponding namespace via the Kyma dashboard.

When you want to create a cluster role, you need to navigate to the Kyma dashboard and using the sidebar menu: Configuration → Cluster Roles. To create a new cluster role, select Create. You need to define all required attributes in the visual Form or within the YAML format. To accelerate the creation of the cluster role, you can make use of the predefined templates, for example, a template for read-only or a template for unlimited authorization and adjust according to your needs. To finish the creation of a cluster role, you need to save through selecting Create again. The cluster role itself does not have an immediate effect. You need to create a cluster role binding for granting authorizations. If you want to create a Role instead of a Cluster Role, the process is identical except you need to first enter the corresponding namespace via the Kyma dashboard.

To assign the (cluster) roles to for example an administrator or developer, you need to create a (cluster) role binding. When creating (cluster) role bindings, you need to define several attributes: the role type, the role you want to bind and the subjects, so the receiver and optionally labels and annotations. Annotations and labels are used in exactly the same way as in the (cluster) role creation.

Role Binding

Role Binding is used to grant permissions defined in a Role to a user or set of users within a specific namespace.

Cluster Role Binding

Cluster Role Binding is used to grant permissions defined in a ClusterRole to a user, set of users, or service accounts across the entire cluster.

Here's an example of a role binding:

12345678910111213
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-configmaps
  namespace: dev
subjects:
- kind: User
  name: johndoe
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: read-configmaps
  apiGroup: rbac.authorization.k8s.io

Here's an example of a cluster role binding:

123456789101112
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets
subjects:
- kind: Group
  name: dev-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: read-secrets
  apiGroup: rbac.authorization.k8s.io

When you want to create a cluster role binding, you need to navigate to the Kyma dashboard and use the sidebar menu: Configuration → Cluster Role Bindings. To create a new Cluster Role Binding, select Create. You can define all required attributes in the visual Form or within the YAML format. To finish the creation of a cluster role binding and activating the binding, you need to save through clicking again on Create. If you want to create a Role Binding instead of a Cluster Role Binding, the process is identical except you need to first enter the corresponding namespace via the Kyma dashboard.