Authorizing Requests and Creating a Cluster

Learn about various authorization methods and choose one for our use.

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-versions if 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.

Create 'go-demo-2'

Let's create the pod in the following code playground:

/
go-demo-2.yml
Authorize requests
Accessing Kubernetes API
Creating Users to Access the Cluster
Mark as Completed
Report an Issue