Author | Ali cloud east sound after-sale technical experts
REVIEW: Other features compared to K8s cluster, mirrored private automatic pulling, it may seem relatively simple. Mirrored pull failure, and the permissions are relevant in most cases. So, in dealing with related issues, we often easy to say: This question is very simple, is certainly a permissions problem. But the reality is that we are always a problem, spent more personal time but can not find the cause. This is mainly we pull the mirror, in particular the principle of private mirroring automatic pulling of deep understanding. This article, the author will lead the discussion under relevant principles.
On order, the private image will automatically pull through the first Ali cloud Acr credential helper component, and then after K8s cluster API Server and kubelet components, and finally to the docker container runtime. But my narrative, will be back to front, from the most basic docker mirrored pull to start.
Mirroring this small pull
For ease of discussion, let’s imagine a scenario. Many people will use the network disk to store files, such as photos, documents and the like. When we access the file, we need to provide the account password to the network disk, network disk service so you can verify our identity. At this time, we are the owner of the resource file, and the network drive is playing the role of the server’s resources. Account password as authentication to ensure that only we can access their own files.
The scenario is simple enough, but soon we will meet new demand: we need to use an online application making the album. According to the normal use of the process, we need to put photos downloaded to the local network disk, and then upload photos to electronic album. This process is more tedious. Optimization method we can think of is to make a photo album application, direct access to the network disk to get our pictures, and that we need to put your username and password to authorize album applications.
This License, the advantage is obvious, but the disadvantages are also obvious: we have network disk username and password to the album service, photo album service to have the ability to read and write network disk, from data security point of view, this is very scary . In fact, this is a general scene will encounter many applications. Private mirror actually pull this scene. Here mirrored warehouse, just as network disk, server resources, and container cluster is a party service, it needs to get access to the mirror repository mirror.
Understand OAuth 2.0 protocol
OAuth protocol is a standard protocol designed to solve the problems of our discussions for version 2.0. Compared to the account password-party applications directly, this protocol uses an indirect way to achieve the same purpose. The following diagram, this agreement includes six steps, namely party applications to obtain user authorization, Token-party applications and obtain a temporary-party applications to access resources.
This six-step is not easy to understand, mainly because of the design of security protocols need to consider the agreement easily demonstrable, so we put it another way to explain this agreement. In simple terms, the agreement actually do two things:
In the case of authorized users, temporary party applications to obtain access token represented;
Then party applications use this token to acquire resources.
If you use an example to illustrate the network disk, it is that the user authorized network disk service creates a temporary token to the Photos app, and then use the Photos app to get the user’s token network disk service photo. OAuth 2.0 is actually the core difference between the various variants, is the first thing, is that users License server’s resources.
The simplest one is for situations where a third-party application itself has control over the resources being accessed. In this case, the three-party application only needs to log in to the resource server with its own password and apply for a temporary token;
When the user of sufficient trust-party applications, directly to the user account password to party applications, application-party applications using the account password to a temporary token server resources;
Users log in to the resource server through the interface provided by the resource server and authorize the resource server to issue tokens to the three applications;
The full implementation of the OAuth 2.0 protocol is also the safest. The third-party application first obtains the user authorization as a captcha, then uses the captcha to exchange the temporary token from the resource server, and then uses the token to access the resources.
As we can see from the above description, the resource server actually plays the roles of authentication and resource management. If the two are implemented separately, the protocol flow will be as follows.
The role played by Docker
The mirror repository registry is currently implemented using the method of “applying account password to three parties”. That is, if the user trusts Docker enough, the user directly gives the account password to Docker, then Docker uses the account password to request a temporary token with the authentication server.
Understanding docker login
First of all, before we pull private Mirror, mirror warehouse to log in using the docker login command. Log in here did not actually build anything warehouse and mirror session and the like. Log on to do three main things:
The first thing is to be with the user account password.
Below, when performing login command, this command will be prompted to enter the account password, this thing is the first step corresponds to the big picture.
The second thing, docker visit https address mirrored warehouse, and confirmed by the challenges v2 interfaces, whether the interface will return Docker-Distribution-Api-Version header field.
This matter is no step corresponding to the protocol in FIG. It does the same ping almost, but confirmation v2 mirror warehouses are online, as well as versions match.
The third thing, docker using the account password provided by the user, access to the authentication server Www-Authenticate header field to return the address of the Bearer realm.
If the access is successful, the authentication server returns a token jwt format to docker, then docker will account password coded and stored in .docker / docker.json file in the user’s directory.
The figure is docker.json file after I log warehouse. This document, as the only evidence docker login warehouse, warehouse operations in the follow-up mirror, will be constantly read and use. The key is base64 encoded information auth account password.
Pull mirroring is how it
Mirror typically comprises two parts, is manifests a file that defines the metadata mirror, the other mirror structure, hierarchical file is the actual image. Pulling substantially mirror around the two part expanded. Because the focus of our article is a permissions problem, so we are here only to pull the file manifests as an example.
Pull manifests file, basically you will do three things:
First, direct access address Docker manifests the mirror, to obtain Www-Authenticate header field. This field contains the address of the authentication server Bearer realm, mirroring service address service, and define the scope and mirroring operations.
Then, docker to get access to the top of Bearer realm address authentication, and access to a temporary token after authentication. This corresponds to enlarge the use of the protocol to obtain a temporary account password token this step, use the account password directly read from docker.json file.
Finally, on top of the token, in a manner of Authorization header field, to download the file manifests. This corresponds to a protocol enlarge download mirrors this step. Of course, because there are layered image files, so the actual docker will use this temporary token repeatedly download files to download a complete image.
K8s achieve private automatic pulling mirroring
K8s cluster generally manage multiple nodes, each node has its own docker environment. If you let users log on separately to mirror the warehouse on the cluster nodes, which is obviously very convenient. To solve this problem, K8s achieve the automatic pulling mirroring function. This core function is the content encoding docker.json, and in part Pod Secret manner as defined pass Kubelet.
Specifically, the following steps:
Create a secret. The secret of .dockerconfigjson data item includes a base64 encoded docker.json file;
Create a pod, pod and the choreography imagePullSecrets point first step in creating a secret;
Kubelet as a cluster controller, monitors the changes in the cluster. When it finds a new pod is created, it will get defined pod through API Server, which includes secret imagePullSecrets references;
Kubelet call docker to create a container and put .dockerconfigjson passed docker;
Finally docker account password using the decoded image pull, and on which a method of the same.
Top of the function, to some extent, solve the problem of cluster node login mirrored warehouse inconvenient. But when we create Pod still need to specify imagePullSecrets to the Pod. K8s by changing access control (Mutating Admission Control) further optimization of the basic functions on top of.
Further optimize reads as follows:
Add the default service account reference to ImagePULLSecrets after you create the secret in the first step;
Pod default default service account, and the service account access controller will change service account in the case cited imagePullSecrets in default, configured to add imagePullSecrets pod’s choreography.
Ali cloud implementation Acr credential helper
Alibaba Cloud container service team implemented the controller Acr credential helper on the basis of K8s. This controller allows users using both Alibaba Cloud K8s Cluster and Container Mirroring service products to automatically use container mirroring in private repositories without having to configure their own account password.
Specifically, the controller will monitor changes in the configmap acr-configuration, the main concern acr-registry and watch-namespace two configurations. Pre-configured designated as a temporary account authorized warehouse mirrored address, after a Configuration Management can automatically pull namespace mirror. When the controller needs to be found namespace configuration is not configured time, it will be to get a temporary account and password by Ali cloud API vessel image of the service.
With a temporary account password, Acr credential helper creates a corresponding Secret namespace and change the default SA to refer to the Secret. Thus, the functions of the controller and K8s cluster itself, together with the automation Ali cloud cluster K8s pull all the processes Mirror mirror on the container Ali cloud service.
to sum up
Private understand mirroring automatic pulling of implementation, there is a difficulty and a focus.
Difficulty is OAuth 2.0 security protocols principle, the above analyzes the OAuth Why would such a design;
Focus is on the cluster controller principle, because the whole process is automated, actually a plurality of controllers includes Admission control and Acr credential helper, including the result of a collaboration.
“Alibaba Cloud native micro-channel public number (ID: Alicloudnative) focus on micro service, Serverless, container, Service Mesh and other technical fields, focusing popular technology trends in cloud native, cloud native large-scale landing practice, do most understand cloud native developers technology public number. “