Shulou(Shulou.com)06/02 Report--

As Kubernetes is widely used and has become an industry-recognized standard framework for container orchestration management, many developers and administrators are familiar with the key concepts of Kubernetes such as deployment, self-scaling, and managing containerized applications. For production deployment, the security of Kubernetes is critical. Therefore, it is necessary to understand how the platform manages the authentication and authorization of users and applications.

We will launch a series of articles to understand the authentication and authorization of Kubernetes and Pod external users within the platform from a practical perspective. I will also explain how to use roles and role bindings to allow or restrict access to resources.

API Server--Kubernetes Gateway

API provides access to various Kubernetes resource objects, such as nodes, tags, Pod, services, deployment, secrets, configmaps, and ingress. These resource objects perform basic CRUD (add, delete, change and search) operations through a simple REST API.

One of the core building blocks of Kubernetes is API Server, which, as the gateway to Kubernetes, is the only entry to access and manage resource objects. Internal components, such as kubelet, scheduler, and controller, access API through API Server for orchestration and coordination. Distributed key / value databases and etcd can only be accessed through API Server.

Cdn.xitu.io/2019/8/14/16c8ddcd3bf5914c?w=805&h=536&f=jpeg&s=51321 ">

Usually we can interact with API Server through the command line tool kubectl. Anything sent from kubectl will eventually be received by API Server. As a result, multiple tools and plug-ins use the same API directly or indirectly.

The request needs to be authenticated by API Server even before the object is accessed or manipulated in the Kubernetes cluster. REST paths use the TLS protocol based on X.509 certificates to protect and encrypt traffic. Kubectl looks for the file ~ / .kube / config to retrieve the CA certificate and client certificate before encoding and sending the request.

ApiVersion: v1clusterscluster: certificate-authority: / Users/janakiramm/.minikube/ca.crt server: https://192.168.99.100:8443 name: minikubecontexts:- context: cluster: minikube user: minikube name: minikubecurrent-context: minikubekind: Configpreferences: {} users:- name: minikube user: client-certificate: / Users/janakiramm/.minikube/client.crt client-key: / Users/janakiramm/.minikube/client.key

The file ca.crt represents the CA certificate used by the cluster, and the files client.crt and client.key are mapped to the user minikube. Kubectl uses these certificates and keys in the context to encode the request.

Can we access API Server through the curl command? The answer is yes.

Even though the most common operation is to use the tunnel protocol by running kubectl proxy, we can still access the path through the certificates available on the computer. In addition to the CA certificate, we also need to embed a base64-encoded token (token) in the header.

How to retrieve the token (token) and the command to invoke API from curl is as follows:

Kubectl config view-o jsonpath=' {"Cluster name\ tServer\ n"} {range. Names [*]} {.name} {"\ t"} {.clu

Cluster name Server minikube https://192.168.99.100:8443

Export CLUSTER_NAME= "minikube"

APISERVER=$ (kubectl config view-o jsonpath= "{.cluster [? (@ .name = =\" $CLUSTER_NAME\ ")] .cluster.server}")

Next, an important task is to get the token associated with the default service account. There is no need to worry about this entity, we will understand it better in later articles.

TOKEN=$ (kubectl get secrets-o jsonpath= "{.items [?) (@ .metadata.annotations ['kubernetes\ .io / service-

Now we have all the data to call curl:

Curl-X GET\-- cacert ~ / .minikube/ca.crt\-- header "Authorization: Bearer $TOKEN"\ $APISERVER/version

Three levels of Kubernetes access Control

As mentioned above, both the user and the Pod are authenticated by API Server before accessing or manipulating the object.

When a valid request is sent to API Server, it goes through three steps before it is allowed or rejected.

1. Identity authentication

Once the TLS connection is established, the request enters the authentication phase, during which the request payload is checked by one or more authenticator modules.

The authentication module is configured by the administrator during the cluster creation process. A cluster may have multiple authentication modules configured, and each module will attempt authentication in turn until one of them is successful.

Client certificates, passwords, plain tokens, bootstrap tokens, and JWT tokens (for service account) are included in the mainstream authentication module. The use of client certificates is the default and is the most common scenario. For a detailed list of authentication modules, see:

Https://kubernetes.io/docs/reference/access-authn-authz/authentication/

Note that Kubernetes is a typical user database or profile that is not used to authenticate users. But it uses strings extracted from X.509 certificates and tokens to pass them to the authentication module. The external authentication mechanism provided by OpenID,Github and even LDAP can be integrated with Kubernetes through one of the authentication modules.

2. Authorization

Once the API request is authenticated, the next step is to confirm that the operation is allowed. This is the second step in the access control process.

When it comes to authorizing a request, Kubernetes focuses on three aspects-the user name of the requester, the request action, and the object affected by the action. The user name is extracted from the header embedded in token, and the action is one of the HTTP verbs (such as GET, POST, PUT, DELETE) mapped to the CRUD operation, and the object is one of the valid Kubernetes objects, such as pod or service.

Kubernetes determines authorization based on an existence policy. By default, Kubernetes follows the concept of closed and open, which means that a clear permission policy is required to access resources.

Like authentication, authorization is configured based on one or more modules, such as ABAC mode, RBAC mode, and Webhook mode. When administrators create a cluster, they configure the authorization module integrated 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). For a detailed list of supported modules, see:

Https://kubernetes.io/docs/reference/access-authn-authz/authorization/#authorization-modules

When you use the default configuration of kubectl, all requests pass, so you are considered a cluster administrator at this time. But when we add new users, they restrict access by default.

3. Admission control

Passing admission control is the last step in the request. Similar to the first two steps, there are many modules for admission control.

However, unlike the first two steps, the final stage can modify the target object. The admission control module acts in the object creation, deletion, update, and connection (proxy) phase, but does not include object reading. For example, the admission control module can be used to modify a request to create a persistent volume declaration (PVC) to use a specific storage class. Another strategy that the module can implement is to extract the image each time the container is created. For more information about the admission control module, please refer to:

Https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/

In this process, if any admission control module refuses, the request is rejected immediately. Once the request passes through all admission controllers, it is validated using the validation process of the corresponding API object, and then written to the object store.

In the next section of the article, we will learn more about creating users and configuring them for authentication. Keep paying attention.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.