The cli interface works similar to other registry related commands:
docker search foo
... searches for foo on the official hub
docker search localhost:5000/foo
... does the same for the private reg at localhost:5000
Signed-off-by: Daniel Menet <membership@sontags.ch>
Upstream-commit: 3231033a80451adff73b53554e27fbabfebb4a4f
Component: engine
renaming this struct to more clearly be session, as that is what it
handles.
Splitting out files for easier readability.
Signed-off-by: Vincent Batts <vbatts@redhat.com>
Upstream-commit: 752dd707ac09cdcd88307b28aa9e39ac7c763b44
Component: engine
functions to pkg/parsers/kernel, and parsing filters to
pkg/parsers/filter. Adjust imports and package references.
Docker-DCO-1.1-Signed-off-by: Erik Hollensbe <github@hollensbe.org> (github: erikh)
Upstream-commit: 4398108433121ce2ac9942e607da20fa1680871a
Component: engine
This lets you specify custom client TLS certificates and CA root for a
specific registry hostname. Docker will then verify the registry
against the CA and present the client cert when talking to that
registry. This allows the registry to verify that the client has a
proper key, indicating that the client is allowed to access the
images.
A custom cert is configured by creating a directory in
/etc/docker/certs.d with the same name as the registry hostname. Inside
this directory all *.crt files are added as CA Roots (if none exists,
the system default is used) and pair of files <filename>.key and
<filename>.cert indicate a custom certificate to present to the registry.
If there are multiple certificates each one will be tried in
alphabetical order, proceeding to the next if we get a 403 of 5xx
response.
So, an example setup would be:
/etc/docker/certs.d/
└── localhost
├── client.cert
├── client.key
└── localhost.crt
A simple way to test this setup is to use an apache server to host a
registry. Just copy a registry tree into the apache root, here is an
example one containing the busybox image:
http://people.gnome.org/~alexl/v1.tar.gz
Then add this conf file as /etc/httpd/conf.d/registry.conf:
# This must be in the root context, otherwise it causes a re-negotiation
# which is not supported by the tls implementation in go
SSLVerifyClient optional_no_ca
<Location /v1>
Action cert-protected /cgi-bin/cert.cgi
SetHandler cert-protected
Header set x-docker-registry-version "0.6.2"
SetEnvIf Host (.*) custom_host=$1
Header set X-Docker-Endpoints "%{custom_host}e"
</Location>
And this as /var/www/cgi-bin/cert.cgi
#!/bin/bash
if [ "$HTTPS" != "on" ]; then
echo "Status: 403 Not using SSL"
echo "x-docker-registry-version: 0.6.2"
echo
exit 0
fi
if [ "$SSL_CLIENT_VERIFY" == "NONE" ]; then
echo "Status: 403 Client certificate invalid"
echo "x-docker-registry-version: 0.6.2"
echo
exit 0
fi
echo "Content-length: $(stat --printf='%s' $PATH_TRANSLATED)"
echo "x-docker-registry-version: 0.6.2"
echo "X-Docker-Endpoints: $SERVER_NAME"
echo "X-Docker-Size: 0"
echo
cat $PATH_TRANSLATED
This will return 403 for all accessed to /v1 unless *any* client cert
is presented. Obviously a real implementation would verify more details
about the certificate.
Example client certs can be generated with:
openssl genrsa -out client.key 1024
openssl req -new -x509 -text -key client.key -out client.cert
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
Upstream-commit: 05243104fc0a0ef9537766cf5bd920824665eb78
Component: engine
These constants don't need to use time.Duration(). Fixup this file since
it seems to be the only one using this style.
Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
Upstream-commit: 4a3b36f44309ff8e650be2cff74f3ec436353298
Component: engine
This continues the effort to separate all registry logic from the
deprecated `Server` object.
* 'search' is exposed by `github.com/dotcloud/docker/registry/Service`
* Added proper documentation of Search while I was at it
Docker-DCO-1.1-Signed-off-by: Solomon Hykes <solomon@docker.com> (github: shykes)
Upstream-commit: c4089ad80bcc1466535696ac0b11d388df529391
Component: engine
This is the first step towards separating the registry subsystem from
the deprecated `Server` object.
* New service `github.com/dotcloud/docker/registry/Service`
* The service is installed by default in `builtins`
* The service only exposes `auth` for now...
* ...Soon to be followed by `pull`, `push` and `search`.
Docker-DCO-1.1-Signed-off-by: Solomon Hykes <solomon@docker.com> (github: shykes)
Upstream-commit: 3d605683b3d272982399635a55ee81b2a7535e81
Component: engine
Backported for backward compatibility.
Docker-DCO-1.1-Signed-off-by: Sam Alba <sam.alba@gmail.com> (github: samalba)
Upstream-commit: de9fba71721f71f86d53cf94504b10dcea80a5bd
Component: engine
The checksum of the payload has to be computed on the Gzip'ed content.
Docker-DCO-1.1-Signed-off-by: Sam Alba <sam.alba@gmail.com> (github: samalba)
Upstream-commit: 3f0886c8c3084341e9ef454bf41445cfc22efca2
Component: engine
roll version and standalone information into the _ping. And to support
Headers they are checked after the JSON is loaded (if there is anything
to load). To stay backwards compatible, if the _ping contents are not
able to unmarshal to RegistryInfo, do not stop, but continue with the
same behavior.
Docker-DCO-1.1-Signed-off-by: Vincent Batts <vbatts@redhat.com> (github: vbatts)
Upstream-commit: 2b855afaeedcab3117876815ec2f8d4450a742b5
Component: engine
For a pull-only, static registry, there only a couple of headers that
need to be optional (that are presently required.
* X-Docker-Registry-Version
* X-Docker-Size
* X-Docker-Endpoints
Docker-DCO-1.1-Signed-off-by: Vincent Batts <vbatts@redhat.com> (github: vbatts)
Upstream-commit: 2a2c694758d6a48125cc9adf446f2054b52db201
Component: engine
