Manage Users and Permissions

Concepts related to RBAC Authorization

As Leaseweb cluster are deployed with this type of authorization, we will dive a bit in this type.

there are 4 type of RBAC objects:

• Role
• ClusterRole
• RoleBinding
• ClusterRoleBinding

Role and ClusterRole

These are rules that govern permissions. They are additive meaning that there is no deny rules. Roles also are namespace specific. ClusterRole are non-namespaced resources.

RoleBinding and ClusterRoleBinding

These represent the permission a Role or ClusterRole has. Like the Role and ClusterRole, Role is for namespaced resources and ClusterRole are to the entire cluster. They have a subject (users, groups, service account) and point to a role being granted.

For more information and details consult the kubernetes official documentation for Role, RoleBinding, ClusterRole and ClusterRoleBinding

Default roles and role bindings

The API server create some default ClusterRoles and ClusterRoleBindings. Many of them are system: prefixed and managed by the control plane. You know if there are default if there is a label like this kubernetes.io/bootstrapping=rbac-defaults

One such ClusterRole is the cluster-admin. When you download the kubeconfig from the customer portal you will have the ClusterRole and ClusterRoleBinding of the cluster-admin. This gives you complete control of the cluster.

Admission control

Kubernetes clusters deployed at Leaseweb comes with the following admission plugins enabled in addition to the default one: NodeRestriction, AlwaysPullImages, ServiceAccount, NamespaceLifecycle, EventRateLimit

The available Admission Control modules are described in Admission Controllers on the Kubernetes official documentation.

Cluster Admin

This is the super user access able to perform any action on any resource in the cluster. You might want after acquiring the kubeconfig from the customer portal to create or restrict access to the cluster as this role can lead to destructive action resulting in a non-functional cluster.

The best practice is to create users and roles for what is needed and to leave the cluster admin super user mostly unused and secured. The added benefit of adding user and roles is that it is easier to audit who and what was perform on the cluster.

Roles (RBAC)

Now that we saw how to create a user or service account to authenticate against the API server with a certificate or a bearer token, we will look into role and permission. We will use the user laurent we created with a certificate in the first part of this document but both user and ServiceAccount are treated the same way.

Now that the user laurent can authenticate against the cluster we need to give him a role which in turn give permission to do action on the cluster. For the purpose of this demonstration, we will create a rolebinding and assign that role to the laurent user.

Permissions

In this section we will look into assigning and revoking permissions.

Assign Permission

We will give the edit permission on the default namespace:

$ kubectl create rolebinding laurent-edit-role --clusterrole=edit --user=laurent --namespace=default

rolebinding.rbac.authorization.k8s.io/laurent-edit-role created

We can then use the auth can-i subcommand of kubectl to see the change:

$ kubectl --kubeconfig=~/certs/laurent.kubeconfig auth can-i get pods

yes

Revoke Permissions

To revoke permission is simple to delete the rolebinding that was created:

$ kubectl delete rolebinding laurent-edit-role

rolebinding.rbac.authorization.k8s.io "laurent-edit-role" deleted

If we use the auth can-i subcommand, we can see that the user laurent cannot get the list of pods now:

$ kubectl --kubeconfig=~/certs/laurent.kubeconfig auth can-i get pods

no

$ kubectl --kubeconfig ~/certs/laurent.kubeconfig cluster-info

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
Error from server (Forbidden): services is forbidden: User "laurent" cannot list resource "services" in API group "" in the namespace "kube-system"

$ kubectl --kubeconfig ~/certs/laurent.kubeconfig get pods
Error from server (Forbidden): pods is forbidden: User "laurent" cannot list resource "pods" in API group "" in the namespace "default"

Test permissions

You can use the auth can-i subcommand provide with kubectl to quickly query the k8s API to see if you can perform a give action. For example, deployment in either the dev or production environment.

$ kubectl auth can-i create deployments --namespace dev yes $ kubectl auth can-i create deployments --namespace prod no

I could do a deployment in dev but not in prod with my current authorization. This can be combined with user impersonation to see what a user can and cannot do with certain action:

$ kubectl auth can-i list secrets --namespace dev --as Manon
 
no

Same could also be user to verify action that service account can perform:

$ kubectl auth can-i list pods \
    --namespace target \
    --as system:serviceaccount:dev:dev-sa
 
yes

To learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules, see Authorization on the Kubernetes official documentation.

Conclusion

We now saw how to assign roles and permission using the RBAC mode but as with authorization there is more method that be used, for more information you can look at authorization on the official Kubernetes documentation.