Basic Principles of docker login commands

Generally, docker client has been installed at the same time during docker installation. You can run the docker version command to view the version information of the client and server.

Client: Version:           18.06.0-ce API version:       1.38 Go version:        go1.10.3 Git commit:        0ffa825 Built:             Wed Jul 18 19:08:18 2018 OS/Arch:           linux/amd64 Experimental:      falseServer: Engine:  Version:          18.06.0-ce  API version:      1.38 (minimum version 1.12)  Go version:       go1.10.3  Git commit:       0ffa825  Built:            Wed Jul 18 19:10:42 2018  OS/Arch:          linux/amd64  Experimental:     false

Docker client is used to initiate an HTTP request to the harbor service. The URL of the harbor registry service in earlier versions is/V1, and the later version of harbor is changed to/V2 to view its nginx configuration.

location /v1/ {      return 404;    }    location /v2/ {      proxy_pass http://ui/registryproxy/v2/;      proxy_set_header Host $$http_host;      proxy_set_header X-Real-IP $$remote_addr;      proxy_set_header X-Forwarded-For $$proxy_add_x_forwarded_for;            # When setting up Harbor behind other proxy, such as an Nginx instance, remove the below line if the proxy already has similar settings.      proxy_set_header X-Forwarded-Proto $$scheme;      proxy_buffering off;      proxy_request_buffering off;    }

Therefore, if your docker version is too old, it will request/V1, and the error will always be reported.

This article mainly explains the underlying execution process and related principles of docker login, docker pull, and other commands. I do not know how many people have misunderstandings about the most basic login commands of docker client, simply think that this is to log on to the harbor warehouse. Some programmers who have been involved for many years may also fall into this misunderstanding. They will not go to the official documents for careful analysis, I think this command is just a simple user name and password logon function.

First, let's talk about the simple docker Login

docker login hub.xxx.comUsername: 2000014559Password: WARNING! Your password will be stored unencrypted in /root/.docker/config.json.Configure a credential helper to remove this warning. Seehttps://docs.docker.com/engine/reference/commandline/login/#credentials-storeLogin Succeeded

After successfully logging on to the console, follow the prompts to know That it stores the username and password in/root/. docker/config. JSON. Go to/root/. docker to view config. JSON.

{        "auths": {                "hub.xxx.com": {                        "auth": "MjAwZZZxNDU1OTpSb299dxedssDU2"                }        },        "HttpHeaders": {                "User-Agent": "Docker-Client/18.06.0-ce (linux)"        }}

Perform Decoding in Linux to check whether

Echo 'auth content '| base64 -- decode

The decoded value is Username: password. Next let's take a look at the requests received by the harbor server. From the nginx service of harbor, we can see that docker login has sent three HTTP requests in total.

Sep 14 14:08:09 172.18.0.1 proxy[13966]: 10.69.56.148 - "GET /v2/ HTTP/1.1" 401 87 "-" Sep 14 14:08:09 172.18.0.1 proxy[13966]: 10.69.56.148 - "GET /service/token?account=2000014559&client_id=docker&offline_token=true&service=harbor-registry HTTP/1.1" 200 897 "-" Sep 14 14:08:09 172.18.0.1 proxy[13966]: 10.69.56.148 - "GET /v2/ HTTP/1.1" 200 2 "-" 

Several key service components of the harbor service are nginx, UI, and registry. As the reverse proxy of the harbor service, nginx receives all requests from the client and then publishes them to other components, the Registry Service requires that all requests entering the registry must carry a valid token; otherwise, 401 is returned and is not authorized.

A. the first GET request/V2 is first forwarded to the UI service through nginx, which is processed by the UI handlechain and then forwarded to the registry service. After the registry service is verified, it is found that the token is not passed in the request header, 401 is returned.

B .doc Ker client requests/service/token immediately after receiving 401. This service is directly forwarded by nginx to the UI component. The UI component detects that the request type is not a repository operation, the username and password must not be blank. For details, see docker login and docker pull to obtain the token parameters.

Docker Login Request Parameters

GET /service/token?account=2000014559&client_id=docker&offline_token=true&service=harbor-registry

Docker pull Request Parameters

GET /service/tokenaccount=2000014559&scope=repository%3Alibrary%2Fprome%2Fnodeexporter%3Apull&service=harbor-registry

When docker login does not have a scope, it will force authentication, that is, after Username: password and base64 encoding, it will be inserted in the authorization in the request header. After the UI authentication is passed, obtain the private_key and generate a token using the JWT algorithm. This token has a validity period.

token info :eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IlFDWTI6Qkk3RTpLMkpWOldYR1g6SEZGSDpMVUJOOlo3Q0k6TFlETDpEUkhaOlBBR1M6RFpQTDpUM1JQIn0.eyJpc3MiOiJoYXJib3ItdG9rZW4taXNzdWVyIiwic3ViIjoiMjAwMDAxNDU1OSIsImF1ZCI6ImhhcmJvci1yZWdpc3RyeSIsImV4cCI6MTUzNjkwNzA4OSwibmJmIjoxNTM2OTA1Mjg5LCJpYXQiOjE1MzY5MDUyODksImp0aSI6IlJuVzhIdGdqdThiQkswbUsiLCJhY2Nlc3MiOm51bGx9.LQveGSQqQ-XvRBYewY2ojqnlNfqhCUhy99s9oQ5WTJ5zdZInBiLJPMKfZReTaZriwTB3cCYwUAvaolLcthLdPZlJil48gG5hWRBeNoiJJNcNHY054wrxhhcJq9v0xcfdJnJAK_sVeuz1pA4v99Z-MMMBYLXHp0mx_sqy1kCJiGrtwU4JshVgG4NBAQLHB8atpdjvfhimFxHfs8-oRyY4EjMJx5-SKYEQadA4SR53VhYaLlL10LBhMSyZj-1C54P1GCf6zn2HHiqaRFOur8zQbX7nNgVz2WszgSCIU9gmxkzS2jD6QWJdfJKvBCHeY8lmoNxGROJvoYAppK6h_f3edOQjgtfrdxyLcneQEtNoVRUzXPwPxtJIh1ISm8xbF0NVfuV2Ntbn4nnUTcJBEw8y4sTyb-l5J8XFzs8idFdN4a7JPSlne4L4lm6pPJsKXTgUp4vFdNvN8lY2pQmtUvEKFPZRgGVFoyIvo8U5KoKX120CGMsXiZ89k_bm98mFwbq2S4hI2jRujUTNopN0qG3TqK2dl6cF_YzoGEt9eU7cblPGpHbE5bqxsXojXsyxn3R8ErmhDo3__-2Z9vyKWTTgy8MLVSj-bMsXfeM3oT6fdNoFHtYxYwQ9FrAiMOO7cirZAETGN5bwoeNRCF1UCuvJgQpzvzH-PKzuez91OdI8NtE, 1800, 2018-09-14T06:08:09Z

C.doc Ker client obtains the token and repeats the request for the first step. At this time, the response result status code is 200. docker client considers the user name and password to be valid and then prompts login success, save it to/root /. docker/config. JSON, used for subsequent operations on the image warehouse, so that users do not enter. From the above analysis, the so-called docker login is not used to call the logon interface of the harbor service, but to verify whether the token can be obtained correctly.

The same is true for docker pull operations. Each pull Operation sends three requests. What is different from docker login is that the repository permission is written to the token when the request generates a token, you are requesting the docker pull operation. The UI service will determine whether the current Warehouse is public and have the read r permission. If the user is the current Warehouse administrator, the user has the rwm permission, if you are a repository developer, you have the RW permission and write the current information to this token. When the Registry Service receives this request, it first uses root. CRT decrypts related information in the token, and then verifies the current operation.

You can use postman to obtain the servicetoken first.

Then we get this token and place it in the authorization in the request header. The front is not basic, but bearer. Here is only a demonstration, not a complete request with the previous one.

Understanding the principles behind these basic docker client commands helps the development and deployment of the harbor server.

Basic Principles of docker login commands