This manual explains how to configure Role-Based Access Control (a.k.a RBAC) on user clusters.
You can grant permission to 3 types of subjects:
user: end user identified by their email
group: named collection of users
service account: a Kubernetes service account that authenticates a process (e.g. Continuous integration)
You can either grant permission on the whole cluster or on specific namespaces by creating bindings.
The RBAC view is organized by subjects. You can choose the subject thanks to the dropbox selector and grant or remove
permission by adding or removing binding.
Role-Based Access Control Predefined Roles
KKP provides predefined roles and cluster roles to help implement granular permissions for specific resources
and simplify access control across the user cluster. All of the default roles and cluster roles are labeled
|cluster-admin||Allows admin access. Allows read/write access to most resources in a namespace, including creating roles and role bindings within the namespace. This role does not allow write access to resource quota or to the namespace itself.|
|edit||Allows read/write access to most objects in a namespace. This role does not allow viewing or modifying roles or role bindings. However, this role allows accessing secrets and running pods as any service account in the namespace|
|view||Allows read-only access to see most objects in a namespace. It does not allow viewing roles or role bindings.|
|list-namespaces||Allows to list namespaces|
|namespace-admin||Allows admin access. Allows read/write access to most resources in a namespace.|
|namespace-editor||Allows read/write access to most objects in a namespace. This role allows accessing secrets and running pods as any service account in the namespace|
|namespace-viewer||Allows read-only access to see most objects in a namespace.|
Manage User Permissions
You can grant permissions to a group by clicking on
The cluster owner is automatically connected to the
cluster-admin cluster role.
Manage Group Permissions
Group are named collection of users. You can grant permission to a group by clicking on
In this example, we grant the role
view on the cluster to the OIDC group
If you want to bind an OIDC group, you must prefix the group’s name with
The kubernetes API Server automatically adds this prefix to prevent conflicts with other authentication strategies
Manage Service Account Permissions
Service accounts are designed to authenticate processes like Continuous integration (a.k.a CI).
In this example, we will:
- create a Service account
- grant permission to 2 namespaces
- download the associated kubeconfig that can be used to deploy workload into these namespaces.
Create a Service Account
Service accounts are namespaced objects. So you must choose in which namespace you will create it. The namespace where
the service account live is not related to the granted permissions.
To create a service account, click on
Add Service Account
In this example, we create a service account named
Grant Permissions to Service Account
You can grant permission by clicking on
In this example, we grant the permission
namespace-admin on the namespace
app-1 to service account
CI of the namespace
You can see and remove binding by unfolding the service account.
Download Service Account kubeconfig
Finally, you can download the service account’s kubeconfig by clicking on the download icon.
You can edit service account’s permissions at any time. There is no need to download the kubeconfig again.
Delete a Service Account
You can delete a service account by clicking on the trash icon. Deleting a service account also deletes all associated binding.
The best way to debug authorizing problems is to enable audit logging
and checks audit logs. For example, check the user belongs to the expected groups (see