Shulou(Shulou.com)05/31 Report--

The main content of this article is "Experimental Analysis of authorized access to Private Security docker registry". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn the "Experimental Analysis of authorized access to Private Security docker registry".

Experimental environment

Server side: start the container using registry v2.1.

Client: machine with Docker installed, ready for pull/push operation

Experimental conditions:

The registry side generates a private key and certificate:

one

Openssl req-newkey rsa:4096-nodes-sha256-keyout certs/domain.key-x509-days 365-out certs/domain.crt

And start:

one

two

three

four

five

six

Docker run-d-p 5000 5000-- restart=always\

-- name registry-v `pwd` / certs:/certs\

-e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt\

-e REGISTRY_HTTP_TLS_KEY=/certs/domain.key\

-v / images/:/var/lib/registry\

Registry:2.1

Experiment one

Test for insecure access:

Certificates are not stored on the docker side. Download the image directly

one

Docker pull registry.test.com:5000/test-busybox:v1

Prompt error:

Error response from daemon: unable to ping registry endpoint https://registry.test.com:5000/v0/v2 ping attempt failed with error: Get https://registry.test.com:5000/v2/: x509: certificate signed by unknown authorityv1 ping attempt failed with error: Get https://registry.test.com:5000/v1/_ping: x509: certificate signed by unknown authority

Indicates that you are accessing a secure warehouse, but access is prohibited. Similarly, if docker push, it will also prompt:

The push refers to a repository [registry.test.com:5000/test-busybox] (len: 1) unable to ping registry endpoint https://registry.test.com:5000/v0/v2 ping attempt failed with error: Get https://registry.test.com:5000/v2/: x509: certificate signed by unknown authorityv1 ping attempt failed with error: Get https://registry.test.com:5000/v1/_ping: x509: certificate signed by unknown authority

At this point, you can turn on the insecure access to docker daemon, that is, find the DOCKER_OPT parameter in the / etc/defaults/docker file, and append-insecure-registry registry.test.com:5000 to it. And restart docker daemon.

Test docker push and docker pull again. Success.

Test at this time:

one

Curl-XGET https://registry.test.com:5000/v2/_catalog

Prompt forbids access:

Curl: (60) SSL certificate problem: self signed certificateMore details here: http://curl.haxx.se/docs/sslcerts.htmlcurl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs) If the defaultbundle file isn't adequate, you can specify an alternate file using the-- cacert option.If this HTTPS server uses a certificate signed by a CA represented inthe bundle, the certificate verification probably failed due to aproblem with the certificate (it might be expired, or the name mightnot match the domain name inthe URL). If you'd like to turn off curl's verification of the certificate, usethe-k (or-- insecure) option.

If you use the-k or-insecure parameters, you can access the corresponding contents of registry.

Experiment two

Test secure access, and the certificate is stored under / etc/docker/certs.d/registry.test.com:5000/.

Under the experimental conditions, first, use the scp command to copy the domain.crt generated previously on the registry side to the docker side. Then create the path: / etc/docker/certs.d/registry.test.com:5000/, and copy the domain.crt over.

Test docker pull / docker push. But it works. Indicates that this certificate is effective immediately.

If domain.crt is removed from this path, docker pull / docker push fails.

Testing for curl:

Curl-XGET prompt forbids access

Accessible in curl-insecure mode

Access using certificates:

one

Curl-- cacert / etc/docker/certs.d/registry.test.com\: 5000/domain.crt-XGET https://registry.test.com:5000/v2/_catalog

It was a success.

Experiment 3

Test secure access and put the certificate at / usr/local/share/ca-certificate/domain.crt.

Under the experimental conditions, first use the scp command to copy the domain.crt generated in front of the registry to the docker, and then move it to the path: / usr/local/share/ca-certificate/.

Docker push / docker pull is a failure at this time. The certificate needs to be updated.

Use the command to update the certificate:

one

Update-ca-certificate

Now docker push / docker pull still fails. You also need to restart docker daemon.

The rebooted docker push / docker pull is successful.

Test curl, if the access without a certificate, it can also be accessed normally.

Similarly, after / usr/local/share/ca-certificate/domain.crt is removed, docker pull / docker push is still successful after updating update-ca-certificate.

Docker push / docker pull failed after rebooting docker daemon.

Experimental conclusion

For private docker registry that uses SSL for authorized access. There are three ways to access it:

1. Modify the configuration of docker daemon and add-- insecure-registry. In the form of access. two。 Copy the certificate to the certs.d path of docker, and the certificate is valid only for docker daemon, effective immediately. Copy the certificate to / usr/local/share/ca-certificate/.... The certificate takes effect globally after updating update-ca-certificate, and there is a minor problem that docker daemon needs to be restarted

There is no problem authorizing access by treating the party with the certificate as a trusted party. In this form, both sides believe that the other is credible.

However, it is also suggested earlier that you can add the-insecure parameter for unsecure access, which means that the docker side does not care whether the registry is trusted, and the register side does not block the access of the docker side. This reduces security a lot.

About update-ca-certificates

You can learn from update-ca-certificates 's man page.

It updates / etc/ssl/certs and reads / etc/ca-certificates.conf, a file in which every line is in / usr/share/ca-certificates is trusted.

And the .crt file under / usr/local/share/ca-certificates is also regarded as credible.

General ca-certificate paths are as follows:

/ etc/ca-certificates/usr/share/ca-certificates/usr/share/doc/ca-certificates/usr/local/share/ca-certificates at this point, I believe you have a better understanding of "Experimental Analysis of authorized access to Private Security docker registry". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.