Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Disclaimer: This blog post focuses on Kyma runtime using the open source version 2.0 of project "Kyma". Keep in mind that adjustments might be needed at a higher release of Kyma.

“Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organization.
RBAC authorization uses the API group to drive authorization decisions, allowing you to dynamically configure policies through the Kubernetes API.“ (source)

RBAC is a commonly used approach in the Kubernetes world to provide authorizations to users. With the migration to open source Kyma 2.0, this will be used as well with SAP BTP, Kyma runtime. Therefore, users are no longer granted access via Role Collections inside the subaccount, but access is controlled directly inside the Kyma runtime itself. Existing access is migrated when a user logs-on for the first time after the migration to open source Kyma 2.

There will be pre-configured roles inside Kyma runtime that are recommended, but you can create your own if you see the need. Here is an overview about the most important ones.


With this Cluster Role, users get full access rights to the whole Kubernetes cluster of Kyma runtime. Access to Kyma system namespaces can be enabled by opening the user’s preferences (to right of Kyma Dashboard) and then activating “Show hidden Namespaces“ and “Allow for modification of protected resources“ inside the section “Clusters”. Users need to be cautious on what they are doing! Even though there is a reconciler running, not all modifications to important components of Kyma runtime are reversible. E.g. don't upgrade components like Istio which are part of the managed service of Kyma runtime. This will cause major issues. It is our obligation to upgrade the delivered components and ensure they interact with each other in the way it is intended.


It’s now possible to provide this role for single namespaces only. This was not possible with previous versions of Kyma runtime. Admins need to create this Role Binding inside a particular namespace.


As before, it’s possible to add developers to single namespaces via Role Bindings. This hasn’t changed compared to before.

Applying roles to users

The first user that creates Kyma runtime is automatically bound to the "cluster-admin" role. This user can add additional ones inside the Kyma dashboard as it is described in the SAP Help Portal. Binding additional users to roles can happen via the UI or by applying a YAML to the cluster or a particular namespace. For the cluster-admin, this could look like this:
kind: ClusterRoleBinding
name: '<Name_of_Role_Binding>'
- kind: User
name: <user_name>
kind: ClusterRole
name: cluster-admin

And then be applied via
kubectl apply -f cluster-admin.yaml --validate=false

What happens if my only cluster-admin user is gone?

In case you have a Kyma runtime where the only user bound to the “cluster-admin” role is not available anymore, you can update your instance via the subaccount of SAP BTP. Visit “Instances and Subscriptions“ and select “…“ next to the Kyma runtime instance. In the second step of the wizard, provide the following JSON parameters to bind the “cluster-admin” role:
"administrators": [
"<user name 1>",
"<user name 2>"]

This should only be used as emergency self-service procedure (link)!


Looking forward to your feedback and comments here.

If you have further questions around Kyma, feel free to post them in the answers area of the SAP Community, here is a link.
To stay up to date with everything Kyma, make sure to visit our Kyma topic page.