kube-apiserver is the gateway component of kubernetes and is the only entry point for kubernetes cluster resource operations, so some processes such as authentication and authorization are obviously implemented based on this component. kubernetes clusters basically perform all operations through the apiserver component, which provides an API in the form of HTTP RESTful for clients inside and outside the cluster to call. kubernetes provides three steps of security for accessing the API: authentication, authorization, and admission control, which are verified when users request apiserver using kubectl, client-go, or the REST API.
- Authentication solves the problem of identifying the user.
- Authorization is specifying what permissions a user has.
- Admission control is acting on resource objects in kubernetes.
Kubernetes API Server Authentication Mechanism (Authentication)
Once a TLS connection is established, the request enters the authentication phase, where the request payload is checked by one or more authenticator modules.
Authentication modules are configured by the administrator during cluster creation, and a cluster may have multiple authentication modules configured, each of which will attempt to authenticate in turn until one of them succeeds.
The main authentication modules include client certificates, passwords, plain tokens, bootstrap tokens, and JWT tokens (for service accounts). The client certificate is used by default and is the most common scheme.
All of kubernetes’ current authentication policies are shown below.
- X509 client certs
- Static Token File
- Bootstrap Tokens
- Static Password File
- Service Account Tokens
- OpenId Connect Tokens
- Webhook Token Authentication
- Authticating Proxy
- Anonymous requests
- User impersonation
- Client-go credential plugins
Kubernetes common authentication mechanisms
X509 client certs
X509 client certs authentication is used for some client access to apiserver and between cluster components, such as when kubectl requests apiserver.
Target audience: External users.
X509 is a digital certificate format standard that is used in the SSL certificates that HTTPS relies on. x509 client certificate authentication is the most used and relatively secure of all kubernetes authentication methods.
Some of the kubernetes deployment tools kubeadm, minkube, etc. are based on certificate authentication. Client-side certificate authentication is called TLS two-way authentication, which means that the server and client verify the correctness of each other’s certificates and coordinate communication encryption schemes if both are correct. The most commonly used X509 certificate creation tools are openssl, cfssl, etc.
Service Account Tokens
serviceaccounts is used for authentication when accessing apiserver in pods, for example when using custom controllers.
Target audience: internal users
There are cases where we want to access the apiserver from inside the pod to get information about the cluster and even make changes to the cluster. In this case, kubernetes provides a special authentication method: serviceaccounts.
Serviceaccounts are namespace oriented. When each namespace is created, kubernetes automatically creates a default serviceaccount under that namespace; and the serviceaccount can only access the resources of that namespace.
Serviceaccounts are a resource in a kubernetes cluster, just like pods, services, and deployments, and users can create their own serviceaccounts.
serviceaccounts contain three main elements: namespace, token, and ca. Each serviceaccount corresponds to a secrets.
Each serviceaccounts corresponds to a secrets, and namespace, token and ca information are stored in secrets and encoded in base64. namespace specifies the namespace where the pod is located, ca is used to verify the apiserver’s certificate, and token is used for authentication. are stored in the pod’s filesystem via mount, and all three are stored in the /var/run/secrets/kubernetes.io/serviceaccount/ directory.
Kubernetes API Server Authorization Mechanism (Authorization)
After a request is authenticated, the next step is to confirm that the operation is allowed to be performed, i.e. Authorization.
For authorizing a request, Kubernetes focuses on three main aspects.
- Username of the requestor
- Request action
- The object affected by the action
The username is extracted from the header of the embedded token, the action is one of the HTTP verbs mapped to a CRUD operation (e.g. GET, POST, PUT, DELETE), and the object is one of the valid Kubernetes resource objects.
Kubernetes determines authorization based on a presence policy. By default, Kubernetes follows a closed and open philosophy, which means that an explicit permission policy is required to access resources.
Similar to authentication, authorization is configured based on one or more modules, such as ABAC mode, RBAC mode, and Webhook mode. When administrators create clusters, they configure authorization modules that integrate with API sever. If multiple modules are in use, Kubernetes checks each module and if any of them authorizes the request, the request is approved. If all modules reject the request, the request is rejected (HTTP status code 403).
kubernetes currently supports the following four authorization mechanisms.
- Node
- ABAC
- RBAC
- Webhook
kubernetes common authorization mechanisms
RBAC (Role-Based Access Control)
RBAC, or Role-Based Access Control, is a mechanism for customizing roles and associating them with specific user, group, and serviceaccounts for the purpose of privilege control.
There are three important concepts in RBAC.
- Role: a role, which is actually a set of rules that defines a set of permissions to operate on Kubernetes API objects.
- Subject: the actee, which includes user, group, serviceaccounts, which in layman’s terms are the users identified in the authentication mechanism.
- RoleBinding: defines the binding relationship between “Role” and “Subject”, that is, the user and the operation privileges are bound.
RBAC actually binds the subject to the role by creating a role through RoleBinding. The following diagram shows several types of binding relationships in RBAC.
Admission Control
Admission Control is the last step of the request. Admission Control has many built-in modules that can act on the object’s “CREATE”, “UPDATE”, " DELETE", “CONNECT” four phases. During this process, if any of the Admission Control modules rejects, then the request is immediately rejected. Once the request has passed all the Admission Controllers it is written to the object store.
The Sidecar injection process for Service Grid Istio technology relies on Kubernetes’ Admission Control implementation.
The Admission Controller is a gateway that intercepts API Server requests (authenticated) and can modify the request object or deny the request. In short, it can be thought of as an interceptor, similar to a middleware in a web framework, which is a means for the Kubernetes API Server to intercept requests.
Why did Kubernetes introduce admission as a mechanism?
- Although Kubernetes has Authentication & Authorization, Authentication & Authorization runs in the filter and can only get the http request header and certificate, but not the request body. So you can’t do any operation on the requested object, because you can’t get the object.
- The Admission Controller runs in the API Server’s add, delete, and check handler, and can naturally manipulate the API resource.
After the API Server receives the client request, it will first authenticate and authorize the request, and only after the authentication and authorization are passed will it proceed to the subsequent endpoint handler processing. The flow of kube-apiserver processing resource requests is as follows.
As you can see, after Authentication & Authorization, the request is handed over to the Admission Controller for further processing, which involves two important phases of Admission, Mutating and Validating, the differences of which are as follows.
- Mutating: allows modification of the request content.
- Validating: does not allow the request to be modified, but can determine whether to proceed with the request or reject it based on the content of the request.