Kubernetes 101 : Securing the cluster - RBAC: Role-Based Access Control -

We start by using the labels - component=kube-apiserver, tier=control-plane - associated with the API-server pod to describe the pod and check the types of authorizations it uses.

We will use the "component=kube-apiserver" label as it is more specific to the API server pod:

RBAC could be enabled on the API server using the command:

RBAC components consist of users, roles, and role bindings.

We can connect to the kubernetes cluster through different types of users.

Kubernetes has a default user for each namespace.

A user can be assigned a role which determines what a user can and can't do in the cluster.

Kubernetes has some built-in roles for user like "cluster-admin", "admin", "edit", ...
Roles are tied to a namespace that is mentioned in the role's Yaml file.

A ClusterRole on the other hand is the non-namespaced version of a role.

We don't need to mention a namespace in its Yaml file:

Remark:

The "apiGroups" refers to the Kubernetes API groups our role could have access to - apps/v1, v1, authorization.k8s.io/v1, ... -.

Now that our ClusterRole is ready, we can assign it to a user. For that purpose, we use a RoleBinding object as below:

We have assigned the "pods-edit" role to the user "Albert" so he can "list", "watch" and "get" pods.

Remark:

In the above example, we have a RoleBinding - namespaced resource - using a ClusterRole - cluster-wide/non-namespaced -, in that case the ClusterRole will be attached to the namespace of the RoleBinding.

To get an idea about what the default roles mentioned earlier can do on a system, we use the below command for the "edit" role: