Kubernetes: Authorization Part1-Authorization Modes Overview

Claire Lee
6 min readMar 27, 2023

--

Kubernetes offers several authorization modes to manage access to cluster resources. Node Authorization authorizes API requests sent by kubelets. ABAC uses attributes to determine access, while RBAC allows administrators to define roles and bind them to specific entities. Webhook mode delegates authorization decisions to external HTTP services. AlwaysAllow mode grants access to all requests, while AlwaysDeny denies all requests. To configure authorization modes in Kubernetes, modify the kube-apiserver.yaml configuration file by adding the desired authorization modes to the --authorization-mode flag. Multiple Authorization Modes allow multiple authorization mechanisms to be used in sequence to control access to Kubernetes resources.

authorization mode overview

When you authenticate to a Kubernetes cluster, it only verifies your identity and establishes a secure connection between you and the cluster. However, authentication alone does not grant you access to any resource in Kubernetes. To access specific resources, you must also be authorized. Authorization is the process of determining whether you have the necessary permissions to access specific resources. Together, authentication and authorization provide a secure access control system for Kubernetes resources.

Authorization Modes

In Kubernetes, there are several authorization mechanisms available that can be used to control access to resources in the cluster, including Node Authorization, Attribute-Based Access Control (ABAC), Role-Based Access Control (RBAC), Webhook, and the AlwaysDeny and AlwaysAllow modes.

Node Authorization

In a Kubernetes cluster, each node runs a kubelet process that communicates with the Kubernetes API server to manage pods and containers running on that node. The kubelet process is responsible for reporting the status of the node and its containers, and for executing commands and pulling images from the container registry.

Node Authorization is a specific type of authorization mode in Kubernetes that is used to authorize API requests made by kubelets. It is not intended for user authorization.

To be authorized by the Node authorizer, a kubelet must use a credential that identifies it as a member of the system:nodes group and has a specific username format of system:node:<nodeName>. Therefore, when a kubelet makes an API request to the Kubernetes API server, it includes this TLS certificate as part of its credentials, along with the system:node:<nodeName> username and system:nodes group. The Node authorizer verifies these credentials to ensure that the kubelet is authorized to make the requested API call.

node authorization

ABAC (Attribute-Based Access Control)

Attribute-Based Access Control (ABAC) uses attributes to determine if a user or process has access to a resource. This policies consist of rules that match attributes in a user’s request with attributes in the policy.

ABAC (Attribute-Based Access Control)

However, managing and updating ABAC policies can become complex, especially as the number of policies and attributes increase. This can lead to potential difficulties in maintaining the system over time.

ABAC drawback

RBAC (Role-Based Access Control)

Role-Based Access Control (RBAC) is a widely adopted authorization mode in Kubernetes that allows cluster administrators to create roles and bind them to users, groups, or service accounts. Roles define a set of specific permissions, while role bindings attach these roles to the appropriate entities, granting administrators precise control over resource access. When changes are required to user access, administrators can easily modify the assigned role, which is immediately reflected across all users assigned to that role. Unlike ABAC, RBAC provides a simpler and more scalable approach to managing access by allowing administrators to define specific roles and permissions for different entities.

RBAC (Role-Based Access Control)

We will dive deeper into RBAC in the next story.

Webhook

Webhook authorization mode allows for custom authorization logic by delegating the authorization decision to an external HTTP service, known as a webhook.

When a user or process sends a request to the Kubernetes API server, the server sends a webhook authorization request to the external authorizer. The authorizer evaluates the request against the defined policies and sends a callback response indicating whether the request is authorized or not. This enables Kubernetes administrators to implement complex and customized authorization rules specific to their organization’s needs using any external system for making authorization decisions, such as an LDAP or Active Directory server, a database, or custom code.

Webhook

AlwaysAllow

AlwaysAllow mode allows all requests without any further authorization checks. This mode can be useful in certain development or testing environments, where ease of access is prioritized over security. However, it is not recommended for use in production environments.

AlwaysDeny

AlwaysDeny mode denies all requests without any further authorization checks. This mode can be useful in highly secure environments where strict access control is critical, or in situations where authorization is not required at all.

Configure Authorization Modes

  1. Edit the kube-apiserver.yaml configuration file located at /etc/kubernetes/manifests/kube-apiserver.yaml
  2. Add the desired authorization mode to the --authorization-mode flag, separating multiple modes with commas.
configure authorization modes

For example, to enable RBAC and Webhook modes, add the following line under the kube-apiserver command:

--authorization-mode=RBAC,Webhook

3. Save the configuration file and restart the kube-apiserver process to apply the changes.

Multiple Authorization Modes

Multiple Authorization Modes allows cluster administrators to use more than one authorization mode to secure access to Kubernetes resources. When a user makes a request to the Kubernetes API server, each authorization mode is evaluated in order until one of them successfully authorizes or denies the request. If all modes fail, the request is denied.

multiple authorization modes

--

--