Kubeapps requires users to login with a Kubernetes API token in order to make requests to the Kubernetes API server as the user. This ensures that a certain user of Kubeapps is only permitted to view and manage applications that they have access to (for example, within a specific namespace). If a user does not have access to a particular resource, Kubeapps will display an error describing the required roles to access the resource.
If your cluster supports Token Authentication you may login with the same tokens. Alternatively, you can create Service Accounts for Kubeapps users. The examples below use a Service Account, as it is the most common scenario.
To create a Service Account for a user "example" in the "default" namespace, run the following:
kubectl create -n default serviceaccount example
To get the API token for this Service Account, run the following:
kubectl get -n default secret $(kubectl get -n default serviceaccount example -o jsonpath='{.secrets[].name}') -o go-template='{{.data.token | base64decode}}' && echo
Kubeapps will install a set of preset Roles and ClusterRoles in your cluster that you can bind to user or Service Accounts. Each Role and ClusterRole pertains to a certain operation within Kubeapps. This documentation describes the roles that should be applied to a user in order to perform operations within Kubeapps.
In order to list and view Applications in a namespace, first we will create a ClusterRole
with read-access to all the possible resources. In case you want
to limit this access, create a custom cluster role or use one of the default ones. Then we will bind that cluster role to our service account.
kubectl apply -f https://raw.githubusercontent.com/kubeapps/kubeapps/master/docs/user/manifests/kubeapps-applications-read.yaml
kubectl create -n default rolebinding example-view \
--clusterrole=kubeapps-applications-read \
--serviceaccount default:example
In order to create, update and delete Applications in a namespace, apply the
edit
ClusterRole in the desired namespace. The edit
ClusterRole should be
available in most Kubernetes distributions, you can find more information about
that role
here.
kubectl create -n default rolebinding example-edit \
--clusterrole=edit \
--serviceaccount default:example
Service Brokers, Classes and Plans in the Service Catalog are cluster-scoped
resources, but Service Instances and Bindings can be restricted to a namespace.
We'll need to define two roles (kubeapps-service-catalog-browse
and
kubeapps-service-catalog-read
) to separate the roles required to view Service
Instances and Bindings so that they can be applied to desired namespaces.
In order to list and view Service Instances in a namespace, we'll create the
kubeapps-service-catalog-browse
ClusterRole in all namespaces and the
kubeapps-service-catalog-read
in the desired namespace.
kubectl apply -f https://raw.githubusercontent.com/kubeapps/kubeapps/master/docs/user/manifests/kubeapps-service-catalog-browse.yaml
kubectl create clusterrolebinding example-kubeapps-service-catalog-browse --clusterrole=kubeapps-service-catalog-browse --serviceaccount default:example
kubectl apply -f https://raw.githubusercontent.com/kubeapps/kubeapps/master/docs/user/manifests/kubeapps-service-catalog-read.yaml
kubectl create -n default rolebinding example-kubeapps-service-catalog-read --clusterrole=kubeapps-service-catalog-read --serviceaccount default:example
In order to create and delete Service Instances and Bindings in a namespace,
create and bind the kubeapps-service-catalog-write
ClusterRole in the desired namespace.
kubectl apply -f https://raw.githubusercontent.com/kubeapps/kubeapps/master/docs/user/manifests/kubeapps-service-catalog-write.yaml
kubectl create -n default rolebinding example-kubeapps-service-catalog-write --clusterrole=kubeapps-service-catalog-write --serviceaccount default:example
In order to resync Service Brokers from the Service Brokers Configuration page,
create and apply the kubeapps-service-catalog-admin
ClusterRole in all namespaces.
kubectl apply -f https://raw.githubusercontent.com/kubeapps/kubeapps/master/docs/user/manifests/kubeapps-service-catalog-admin.yaml
kubectl create clusterrolebinding example-kubeapps-service-catalog-admin --clusterrole=kubeapps-service-catalog-admin --serviceaccount default:example
In order to list the configured App Repositories in Kubeapps, bind users/groups Subjects to the Kubeapps apprepositories-read
clusterrole in the namespace Kubeapps was installed into by the helm chart.
export KUBEAPPS_NAMESPACE=kubeapps
kubectl create -n $KUBEAPPS_NAMESPACE rolebinding example-kubeapps-repositories-read \
--clusterrole=kubeapps:$KUBEAPPS_NAMESPACE:apprepositories-read \
--serviceaccount default:example
Likewise to the read access bind users/group Subjects to the
Kubeapps apprepositories-write
ClusterRole in the namespace Kubeapps is installed in
for users to create and refresh App Repositories in Kubeapps
export KUBEAPPS_NAMESPACE=kubeapps
kubectl create -n $KUBEAPPS_NAMESPACE rolebinding example-kubeapps-repositories-write \
--clusterrole=kubeapps:$KUBEAPPS_NAMESPACE:apprepositories-write \
--serviceaccount default:example
To give permissions in multiple namespaces, simply create the same RoleBindings in each namespace you want to configure access for. For example, to give the "example" user permissions to manage Applications in the "example" namespace:
kubectl create -n example rolebinding example-kubeapps-applications-write --clusterrole=kubeapps-applications-read --serviceaccount default:example
kubectl create -n example rolebinding example-kubeapps-applications-write --clusterrole=kubeapps-applications-write --serviceaccount default:example
Note that there's no need to recreate the RoleBinding in the namespace Kubeapps is installed in that is also needed, since that has already been created.
If you want to give access for every namespace, simply create a ClusterRoleBinding instead of a RoleBinding. For example, to give the "example" user permissions to manage Applications in any namespace:
kubectl create clusterrolebinding example-kubeapps-applications-write --clusterrole=kubeapps-applications-read --serviceaccount default:example
kubectl create clusterrolebinding example-kubeapps-applications-write --clusterrole=kubeapps-applications-write --serviceaccount default:example
A simpler way to configure access for Kubeapps would be to give the user cluster-admin access (effectively disabling RBAC). This is not recommended, but useful for quick demonstrations or evaluations.
kubectl create serviceaccount kubeapps-operator
kubectl create clusterrolebinding kubeapps-operator --clusterrole=cluster-admin --serviceaccount=default:kubeapps-operator