Kubernetes- Authentication & Authorization
Authentication:
Kubernetes cluster consists of various components- The mater node & worker nodes. There are different types of users accessing this clusters- The admin, developers , end user accessing the application and other third party applications accessing the cluster for integration purpose.
it’s necessary to secure the cluster. It may be related to internal communication between the components or management access to cluster through Authentication & Authorization .
Let’s look how we can secure kubernetes management through Authorization mechanism-
Primarily we will talk about user access to kubernetes cluster for administrative purpose. So, we have 2 types of users- (Admin/Developers — User) & BOTS — (Services/Process/Applications — Service Account)
Kubernetes doesn’t manage the user account natively, it depends on external source like — file with user details, ldap , certificates to manage the users. So, we can’t create the users to lists the user in kubernetes. Sample example shown in below image.
However, in case of service Account kubernetes can manage them. Sample example shared below.
Here, we will explore more on kubernetes users.( Admins/ Developers ). All user access in kubernetes is managed by API Server whether we access using the kubectl tool or through API call all request go through the Kube-api server. The Kube api server Authenticate the request and process further.
How does Kube-Api server Authenticates?
There are different Authentication mechanism that can be configured.
- Static password file : User name name password in static password file.
- Static token file: User name and token in static token file.
- Certificates : Authenticate using certificates.
- identity services: Like ldap.
Authorization:
As we have learnt about the Authentication in above notes, So, once user have been authenticated or gain access— Authorization decide what they can do.
Why do we need authorization?
As a admin for the kubernetes cluster ,we can perform all sorts of operation, viewing details, updating the configuration or deleting the resources.
We may also have other users accessing the clusters — Developers , Tester or other application ( monitoring , CI/CD tools)..etc. So, we will be creating an account for them to access the kubernetes cluster. This is to control the access and only provide minimum access to other users
Different Authorization Mechanism Supported by Kubernetes:
- Node :- In K8s cluster different components access the Kube-API server for different management purpose. Example- the kubelet access the Kube-API server to Read- Services , endpoints, nodes , pods and also to Write the node status, Pod status ..etc. These requests are handled by special Authorizer called — Node Authorizer. During the certification creation -Kubelet is made a part of system Node group and name prefix with System: node. So, any request coming from the user with name System: node and part of system node group is Authorized by node Authorizer.
- ABAC (Attributes based Authorization):- Associate user with some set of permission.
- RBAC (Role Based Authorization):- In RBAC , instead of directly associating a users or group to specific permission we define a Role. In this below image for dev-user we created a role with set of permission for developer and associate all users to that role. Similarly, for other users similar role. Whenever a change is required to user access, we can just modify role and it will immediately reflect for all users. RBAC provides more stand approach to managing access within Kubernetes cluster
- Webhook: An external service for authorization.
There are 2 more Authorization mode- AlwaysAllow & AlwaysDeny.
Where are this mode configured?
They are configured in Api server:
- if this config is not set by default it is set to AlwaysAllow- Will allow all request without checking authorization.
- We can configured (comma) separated multiple Authorization mode.
- If multiple mode is configured- the request are Authorized in order specified in configuration — Node →RBAC →Webhook.
