We start by using the labels - component=kube-apiserver, tier=control-plane - associated with the API-serverpod 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 serverpod:
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:
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.
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: