Hello everyone! I’m here to be a lighthouse for those navigating the world of Kubernetes. π§ Today, we’re going to delve into the seemingly complex but crucial Kubernetes Authentication and Authorization system in an easy-to-understand and detailed manner.
A Kubernetes cluster is a valuable space where countless containers and important applications reside. We certainly can’t let just anyone enter and manipulate it at will, can we? That’s why Kubernetes has a strict access control system.
This system is broadly divided into two stages:
- Authentication π€: “Who are you?” This is the identity verification stage.
- Authorization π: “Do you have permission to perform this action?” This is the stage where a verified user is granted permission to perform specific actions.
In today’s post, we will focus on the second stage, Authorization, which is about “what can be done?” and explore various methods!
β RBAC (Role-Based Access Control): Role-Based Access Control
“You are a ‘developer’ role, so you can only access the ‘development server’.”
This is the most widely used method and officially recommended by Kubernetes. It’s a way to assign roles to individuals within an organization and predefine what they can do (permissions) based on that role.
π’ Let’s compare it to a company:
- User: Company employee π§βπΌ
- Role: Job titles like ‘HR Team’, ‘Development Team’, ‘Design Team’ π·οΈ
- Permission: ‘HR Team’ can view employee information, ‘Development Team’ can access development servers π
- Resource: Employee information files, development servers π»
As such, RBAC doesn’t grant permissions directly to users one by one, but rather uses an intermediate step called a ‘Role’ to group and manage permissions. This makes permission management much easier and more intuitive. For example, when a new developer joins, simply assigning them the ‘Development Team’ role grants them all necessary permissions at once.
RBAC is implemented in Kubernetes through objects such as Role, ClusterRole, RoleBinding, and ClusterRoleBinding.
π§ ABAC (Attribute-Based Access Control): Attribute-Based Access Control
“You are connecting from ‘Korea’, belong to the ‘administrator’ group, and it’s ‘business hours’, so you can access ‘all servers’.”
ABAC goes a step further than RBAC, allowing access based on policies created by combining various attributes. It’s a very flexible and powerful method.
The attributes mentioned here can be very diverse:
- User attributes: User’s name, role, group affiliation, security level, etc.
- Resource attributes: File type, sensitivity, owner, etc.
- Environment attributes: Connection time, connection location (IP address), device used, etc.
π¬ Let’s compare it to a movie theater: To watch a movie rated ’19 and over’, both the user attribute [Age: 19 or older] and the resource attribute [Movie Rating: 19] must be met for entry.
ABAC allows for very fine-grained control by dynamically combining multiple conditions, but it has the disadvantage of being more complex to create and manage policies compared to RBAC.
π€ Node Authorization: Node Authorization
“Node 1, you can only retrieve information about the Pods assigned to you. No other node information!”
As the name suggests, this is an authorization mode specific to Nodes. More precisely, it’s a special-purpose feature that authorizes requests sent to the API server by kubelet, the agent running on each node.
Kubelet, the worker on each cluster node, must constantly communicate with the central management API server to know which Pods to launch on its node, what configuration values (Secret, ConfigMap) are needed, and so on. π
At this point, Node Authorization plays a role in strictly limiting kubelet’s access to only resources related to itself. If kubelet on Node A tries to retrieve information from Node B, which is completely unrelated, Node Authorization will block the request with “Access Denied! π‘οΈ”. This is an important feature that further enhances cluster security.
Webhook Mode: Webhook Mode
“I’m not sure if this user can perform this action… I’ll go ask an external expert!”
This is a method where Kubernetes’ authorization decisions are not processed internally, but rather queried (delegated) to another external system.
‘Webhook’ refers to sending an HTTP request to a specified URL when a particular event occurs. In the authorization process, it works as follows:
- A user requests a specific action from the API server. π
- The Kubernetes API server sends an HTTP request to an external service URL configured in Webhook mode, asking, “This user wants to perform this action, should I allow it?” β‘οΈ External Service
- The external service, upon receiving the request, checks permissions according to its own logic (e.g., integration with an internal company authentication system) and responds with “Yes, allow” or “No, deny”. β / β
- The API server receives the response from the external service and finally processes or rejects the user’s request.
This method is very useful when you already have a complex authentication/authorization system built within your company, or when you want to apply special rules that are difficult to implement with Kubernetes’ basic authorization models alone.
β¨ Concluding Remarks
Today, we explored various methods of Authorization, the gatekeeper that safely protects Kubernetes clusters.
- RBAC: The most standard and easy-to-manage role-based method.
- ABAC: A method that allows for fine-grained and dynamic control by combining multiple attributes.
- Node Authorization: A method that enhances node security by limiting Kubelet’s permissions.
- Webhook Mode: A flexible method that delegates authorization decisions to external systems.
The choice of method depends on your environment and security requirements. However, in most cases, starting with RBAC and combining other methods as needed will be the best starting point.
I hope you make your Kubernetes clusters even safer and more robust! πͺ
Tags: Kubernetes, Kubernetes, Authentication, Authorization, Security, RBAC, ABAC, NodeAuthorization, Webhook, K8s, DevOps
Leave a Reply