Role-based access control

Introduction

Kiali supports role-based access control (RBAC) when using any authentication strategy other than anonymous.

Although the anonymous strategy does not support RBAC, you can still limit privileges if using an OpenShift cluster. See the access control section in Anonymous strategy.

Kiali uses the RBAC capabilities of the underlying cluster. Thus, RBAC is accomplished by using the standard RBAC features of the cluster, which is through ClusterRoles, ClusterRoleBindings, Roles and RoleBindings resources. Read the Kubernetes RBAC documentation for details. If you are using OpenShift, read the OpenShift RBAC documentation.

In general, Kiali will give access to the resources granted to the account used to login. Specifically, depending on the authentication strategy, this translates to:

For example, if you are using the token strategy, you would grant cluster-wide privileges to a ServiceAccount with this command:

$ kubectl create clusterrolebinding john-binding --clusterrole=kiali --serviceaccount=mynamespace:john

and if you are using openshift or openid strategies, you could assign privileges with any of these commands:

$ kubectl create rolebinding john-openid-binding --clusterrole=kiali --user="john@example.com" --namespace=mynamespace
$ oc adm policy add-role-to-user kiali john -n mynamespace # For OpenShift clusters

Please read your cluster RBAC documentation to learn how to assign privileges.

Minimum required privileges to login

The get namespace privilege in some namespace is the minimum privilege needed in order to be able to login to Kiali. This means you need the following minimal Role bound to the user that wants to login:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
rules:
- apiGroups: [""]
  resources:
  - namespaces
  verbs:
  - get

This minimal Role will allow a user to login. Kiali may work partially, but some pages may be blank or show erroneous information, and errors will be logged constantly. You will need a broader set of privileges so that Kiali works fine.

Privileges required for Kiali to work correctly

The default installation of Kiali creates a ClusterRole with the needed privileges to take the most advantage of all Kiali features. Inspect the privileges with

kubectl describe clusterrole kiali

Alternatively, check in the Kiali Operator source code. See either the Kubernetes role.yaml template file, or the OpenShift role.yaml template file.

You can use this ClusterRole to assign privileges to users requiring access to Kiali. You can assign privileges either in one namespace, which will result in users being able to see only resources in that namespace; or assign cluster-wide privileges.

For example, to assign privileges to the john user and limiting access to the myApp namespace, you could run either:

$ kubectl create rolebinding john-binding --clusterrole=kiali --user="john" --namespace=myApp
$ oc adm policy add-role-to-user kiali john -n myApp # For OpenShift clusters

But if you need to assign cluster-wide privileges, you could run either:

$ kubectl create clusterrolebinding john-admin-binding --clusterrole=kiali --user="john"
$ oc adm policy add-cluster-role-to-user kiali john # For OpenShift clusters

In case you need to assign a more limited set of privileges than the ones present in the Kiali ClusterRole, create your own ClusterRole or Role based off the privileges in Kiali’s ClusterRole and remove the privileges you want to ban. You must understand that some Kiali features may not work properly because of the reduced privilege set.