Kubernetes RBAC (Role-Based Access Control)

Today, we will discuss 3'A Security of the Kubernetes cluster, ie Authentication, Authorization, and Admission controller.

We will break this explanation into four parts ie. Users/Service Account, Authentication, Authorization, and Admission controller.

Admin/Developer/Service Account

• An Admin user can be the user who performs the administrative task, deployment, deletion with all root privileges.
• A developer has limited access to the cluster that may include read, write and view permission.
• A service Account is a user which is used by other processors or services or applications that require access to the cluster eg. we want to connect the Kubernetes cluster from CI/CD tools such as Jenkins, Gitlab, etc.

all user access is managed by the API server, whether you’re accessing the cluster through a control tool(kubectl) or the API directly.

Let’s imagine that we have successfully configured the Kubernetes and users or service accounts will send an API request to perform some action then Kubernetes will perform the following validations.

Authentication

• In this stage, the Kubernetes will evaluate who is this user, does the credential really matches our expectations, the request is really from a genuine user.
• If yes, it passes to the next stage, if not, the request will be denied as shown in the above diagram.
• There are mainly three major groups that Kubernetes can employ for authenticating the users.
• First, with a text file with username and password and other details, Second authentication method includes x509 certificates, and third with bearer tokens.
• And the if request will be passed on to the next stage, which is authorization.

Authorization

• Just because the request comes from a genuine and authenticated user, that doesn’t mean that we should give full equal access rights to all of them.
• So in this stage, Kubernetes determine which actions are permitted to the user, the user belongs to which group, and what roles are assigned to the user, does the user has the full right that he/she requested for?
• For example, we want the Web development team members to have the ability to create, check the deployment and service but should not have the right access for underlying hardware and delete permissions and etc.
• One of the popular and default authorization modules is role-based Access Control and there are about six authorization modules that you can configure.
• And finally, If this request goes well, it passes to the Admission controller, if not the API request is denied right here.

Admission controller

• The request comes from a real authenticated user and that user is authorized to perform the requested request.
• Now, what we care about is whether the request meets the criteria, is it a valid request? does this request has proper syntax?
• if not what actions to take, should we reject the request entirely?
• It limits requests to create, delete, modify objects or connect to the proxy. but do not limit requests to read objects.
• So in this final stage, if the admission controller checks pass, API requests will be processed.

In Short

• The first Kubernetes request will go through the authentication and check the request is coming from a real authenticated user if yes, the request is passed to the second stage.
• Kubernetes will validate if this user is allowed to perform the requested action. If yes, then it passes to the final stage.
• In this stage three, the Kubernetes checks whether the request meets the criteria, considers it to be a valid request, if not, what actions to take.
• If all checks pass, API requests will be processed.

Also, check

Kubernetes Tutorials