Authorizing Requests and Creating a Cluster
Learn about various authorization methods and choose one for our use.
We'll cover the following
Authorization methods#
Just like almost everything else in Kubernetes, authorization is modular. We can choose to use Node, ABAC, Webhook, or RBAC authorization.
Node: Node authorization grants permissions to kubelets based on the Pods they are scheduled to run.
ABAC: Attribute-based access control (ABAC) is based on attributes combined with policies and is considered deprecated in favor of RBAC.
Webhooks: Webhooks are used for event notifications through HTTP POST requests.
RBAC: Role-based access control (RBAC) grants (or denies) access to resources based on roles of individual users or groups.
We will go with RBAC#
Among the four authorization methods, RBAC is the right choice for user-based authorization. Since we’ll focus this chapter on the exploration of the means to authorize humans, RBAC will be our primary focus.
What can we do with RBAC?
- 
We can use it to secure the cluster by allowing access only to authorized users.
 - 
We can define roles that would grant different levels of access to users and groups. Some could have god-like permissions that would allow them to do almost anything, while others could be limited only to basic non-destructive operations. There can be many other roles in between.
 - 
We can combine RBAC with Namespaces and allow users to operate only within specific segments of a cluster.
 - 
There are many other combinations we could apply depending on particular use-cases.
 
We’ll leave the rest for later and explore details through a few examples. As you might already suspect, we’ll kick it off with a new k3d cluster.
To check if RBAC is enabled on k3d run
kubectl api-versionsif it is enabled you should see.rbac.authorization.k8s.io/v1.
It might come in handy to have a few objects in the cluster so we’ll deploy the go-demo-2 application. We’ll use it to test different permutations of the authorization strategies we’ll use soon.
The definition of the go-demo-2 application is the same as the one we created in the previous chapters so we’ll skip the explanation and just execute kubectl create.
Let's create the pod in the following code playground:
/
- go-demo-2.yml
 
