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

Original articles, welcome to reprint. Reprint please indicate: reproduced from IT Story Association, thank you!

Original link address: kubernetes understanding Authentication and Authorization of docker (37)

Starting from this section, the deployment of a complete kubernetes cluster, that is, the addition of authentication and authorization on the basis of the previous basic cluster, the industry's evaluation of kubernetes has a steep learning curve and is not easy to get started, mainly due to the installation and deployment of the environment. Half of the ultimate reasons for the installation and deployment of the environment are attributed to its authentication and authorization.

Understand why authentication authorization needs authentication.

To understand authentication, we have to start with what problems to solve and what problems to prevent.

What problems should be prevented? Is it to prevent someone from * * your cluster, root your machine to make our cluster still safe? Come on, you've got all the root, so you can do whatever you want, it's hard to prevent.

In fact, the purpose of network security itself is to solve the problem of how to prevent it under certain assumptions. For example, a very important assumption is that the communication network between two nodes or ip is untrusted and may be stolen or tampered with by a third party. Just like when we sent a note to the girl we loved at school, the process of transmission may be peeked by other students, and even the content may be changed from I like you to I don't like you. Of course, this assumption is not randomly come up with, but from the current situation of network technology and the actual problems found, summed up. The authentication of kubernetes is also realized from this problem.

Concept carding

In order to solve the problems mentioned above, kubernetes does not need to find its own solutions. After all, it is a problem at the level of network security, a problem that every service will encounter, and there are mature solutions in the industry to solve it. Here let's take a look at the industry solutions and related concepts.

Symmetric encryption / asymmetric encryption

These two concepts belong to cryptography and are not easy to understand for those who have never come into contact with them. Symmetric encryption will correspond to a series of encryption algorithms. If key encrypts data, it must use the same key and the same algorithm to decipher plaintext, which is relatively fast, but everyone uses a plaintext secret key, so the security is not good. If a person's key is leaked, it is very dangerous. Asymmetric encryption, I use a key to encrypt the data, only another key can be used to decrypt it, this algorithm is an asymmetric encryption algorithm, the characteristics are relatively secure, do not need too many keys, the security is greatly improved. SSL/TLS

Now that we know about symmetric and asymmetric encryption, we can take a look at SSL/TLS. SSL and TLS can think that the mechanism of the old version and the new version of something is based on symmetrical encryption and asymmetric encryption. It is a layer of communication protocol, which is based on the middle layer protocol above the transport layer and below the application layer, to ensure the security and reliability of transmission. First establish the method of asymmetric encryption to communicate with each other, we reach an agreement, use the randomly generated secret key for symmetrically encrypted transmission, symmetric encryption is not secure, the secret key is not secure, the randomly generated secret key, this secret key does not want others to know, this secret key communicates through asymmetric encryption to reach an agreement, old man, we use a certain string as the secret key. This session is made into a secret key for symmetrically encrypted communication. What is authorization?

The concept of authorization is much simpler, that is, who has what kind of authority, generally through the role as a link to put them together. That is, a role has multiple permissions on the one hand and multiple people on the other. This establishes a relationship between people and permissions.

Authentication and authorization of kubernetes

Basically, all operations of the Kubernetes cluster are done through the kube-apiserver component, which provides API in the form of HTTP RESTful for clients inside and outside the cluster to call. It should be noted that the authentication and authorization process only exists in the API in the form of HTTPS. That is, if the client connects to the kube-apiserver using HTTP, there is no authentication authorization. So, it can be set up that HTTP is used for communication between components within the cluster and HTTPS is used outside the cluster, which increases security and is not too complex.

There are three steps to access APIServer, the first two are authentication and authorization, and the third is Admission Control, which can also improve security to some extent, but it is more of a resource management role.

Certification of kubernetes

Kubernetes provides a variety of authentication methods, such as client certificates, static token, static password files, ServiceAccountTokens, and so on. You can use one or more authentication methods at the same time. As long as it passes any one of them, it is considered to be certified. Below we know a few common authentication methods.

Client certificate authentication

Client certificate authentication is called TLS two-way authentication, that is, the server and client verify the correctness of the certificate each other, and coordinate the communication encryption scheme when all are correct.

In order to use this scheme, api-server needs to be enabled with the-- client-ca-file option. Boot Token

When we have a large number of node nodes, it is troublesome to configure TLS authentication for each node node manually. In this case, we can use the authentication method of booting token, as long as we need to enable the experimental-bootstrap-token-auth feature in api-server, and automatically issue a certificate for node after the client's token information matches the predefined token authentication. Of course, booting token is a mechanism that can be used in a variety of scenarios. Service Account Tokens certification

In some cases, we want to access api-server within pod, get information about the cluster, or even make changes to the cluster. In view of this situation, kubernetes provides a special authentication method: Service Account. Service Account, like pod, service and deployment, is a resource in the kubernetes cluster, and users can also create their own Service Account.

ServiceAccount mainly contains three parts: namespace, Token and CA. Namespace specifies that the namespace,CA where the pod is located is used to verify the certificate of the apiserver, and the token is used as authentication. They are all stored in the file system of pod through mount. Authorization of kubernetes

The new role access control mechanism (Role-Based Access,RBAC) in the Kubernetes1.6 version allows cluster administrators to perform more precise resource access control based on the roles of specific consumers or service accounts. In RBAC, permissions are associated with roles, and users get permissions for those roles by becoming members of the appropriate roles. This greatly simplifies the management of permissions. In an organization, roles are created to complete a variety of tasks, users are assigned roles according to their responsibilities and qualifications, and users can be easily assigned from one role to another.

At present, there are a series of authentication mechanisms in Kubernetes, because of the input and preference of the Kubernetes community, RBAC is a better choice than other authentication mechanisms. We will gradually learn more about how the specific RBAC is reflected in the kubernetes system in the later deployment.

2.3 AdmissionControl for kubernetes

AdmissionControl-admission control is essentially a piece of admission code. In the process of request to kubernetes api, the sequence is as follows: first authenticate-authorize, then perform admission operation, and finally operate on the target object. This access code is in api-server and must be compiled into a binary before it can be executed.

When a request is made to the cluster, each admission control code is executed in a certain order. If an admission control rejects the request, the result of the entire request will be returned immediately and the user will be prompted for the corresponding error information.

The common components (control codes) are as follows:

AlwaysAdmit: allow all requests AlwaysDeny: disable all requests, mostly used in the test environment ServiceAccount: it automates serviceAccounts, it helps serviceAccount do some things, such as if pod does not have a serviceAccount attribute, it automatically adds a default and ensures that the serviceAccount of pod always has a LimitRanger: he watches all requests to make sure that there are no violations of defined constraints, which are defined in the LimitRange object in namespace. If you use the LimitRange object in kubernetes, you must use this plug-in. NamespaceExists: it observes all requests, and if the request attempts to create a namespace that does not exist, the request is rejected.

PS: I'd like to talk about the theory this time, and understand it, and start building it directly next time.

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.