Remove quay.io from list of search registries, removes risk of squatters.

Update man pages to match upstream
This commit is contained in:
Daniel J Walsh 2020-02-06 12:09:25 -05:00
parent d63507ed08
commit 932609e3b4
No known key found for this signature in database
GPG Key ID: A2DF901DABE2C028
5 changed files with 78 additions and 5 deletions

View File

@ -109,6 +109,26 @@ internet without having to change `Dockerfile`s, or to add redundancy).
*Note*: Redirection and mirrors are currently processed only when reading images, not when pushing
to a registry; that may change in the future.
#### Normalization of docker.io references
The Docker Hub `docker.io` is handled in a special way: every push and pull
operation gets internally normalized with `/library` if no other specific
namespace is defined (for example on `docker.io/namespace/image`).
(Note that the above-described normalization happens to match the behavior of
Docker.)
This means that a pull of `docker.io/alpine` will be internally translated to
`docker.io/library/alpine`. A pull of `docker.io/user/alpine` will not be
rewritten because this is already the correct remote path.
Therefore, to remap or mirror the `docker.io` images in the (implied) `/library`
namespace (or that whole namespace), the prefix and location fields in this
configuration file must explicitly include that `/library` namespace. For
example `prefix = "docker.io/library/alpine"` and not `prefix =
"docker.io/alpine"`. The latter would match the `docker.io/alpine/*`
repositories but not the `docker.io/[library/]alpine` image).
### EXAMPLE
```
@ -167,7 +187,29 @@ registries = ['registry3.com']
registries = ['registry.untrusted.com', 'registry.unsafe.com']
```
## NOTE: RISK OF USING UNQUALIFIED IMAGE NAMES.
Pulling an image that is not fully qualified, i.e., one that includes the
image name but does not include the registry or tag, is not recommended.
There is a risk that the image being pulled could be spoofed. An example
of this would be if a user wanted to pull an image named `foobar` from a
registry and expect it to come from myregistry.com. If myregistry.com is
not first in the search list, an attacker could place a different `foobar`
image at a registry earlier in the search list. Now you would accidentally
run the attackers code rather than the intended content. Registries that
are added to this list should be completely controlled, i.e., not allow
unknown/arbitrary users being able to create accounts with arbitrary names
to prevent an image from being spoofed, squatted or otherwise made
insecure. If it is necessary to use one of these registries, it should be
added at the end of the list.
It is recommended to use fully-qualified images for pulling as
the destination registry is unambiguous. Pulling by digest
(i.e., quay.io/repository/name@digest) further eliminates the ambiguity of
tags.
# HISTORY
Dec 2019, Warning added for unqualified image names by Tom Sweeney <tsweeney@redhat.com>
Mar 2019, Added additional configuration format by Sascha Grunert <sgrunert@suse.com>
Aug 2018, Renamed to containers-registries.conf(5) by Valentin Rothberg <vrothberg@suse.com>

View File

@ -24,7 +24,7 @@ dont matter.
The contents of these files are merged together; to have a well-defined and easy to understand
behavior, there can be only one configuration section describing a single namespace within a registry
(in particular there can be at most one one `default-docker` section across all files,
and there can be at most one instance of any key under the the `docker` section;
and there can be at most one instance of any key under the `docker` section;
these sections are documented later).
Thus, it is forbidden to have two conflicting configurations for a single registry or scope,
@ -98,7 +98,7 @@ docker:
For developers in `example.com`:
- Consume most container images using the public servers also used by clients.
- Use a separate sigure storage for an container images in a namespace corresponding to the developers' department, with a staging storage used before publishing signatures.
- Use a separate signature storage for an container images in a namespace corresponding to the developers' department, with a staging storage used before publishing signatures.
- Craft an individual exception for a single branch a specific developer is working on locally.
```yaml

View File

@ -145,7 +145,12 @@ The `storage.options.overlay` table supports the following options:
ignore_chown_errors can be set to allow a non privileged user running with a single UID within a user namespace to run containers. The user can pull and use any image even those with multiple uids. Note multiple UIDs will be squashed down to the default uid in the container. These images will have no separation between the users in the container. (default: false)
**mount_program**=""
Specifies the path to a custom program to use instead of using kernel defaults for mounting the file system.
Specifies the path to a custom program to use instead of using kernel defaults
for mounting the file system. In rootless mode, without the CAP_SYS_ADMIN
capability, many kernels prevent mounting of overlay file systems, requiring
you to specify a mount_program. The mount_program option is also required on
systems where the underlying storage is btrfs, aufs, zfs, overlay, or ecryptfs
based file systems.
mount_program = "/usr/bin/fuse-overlayfs"
**mountopt**=""

View File

@ -8,8 +8,29 @@
#
# Registries to search for images that are not fully-qualified.
# i.e. foobar.com/my_image:latest vs my_image:latest
#
# NOTE: RISK OF USING UNQUALIFIED IMAGE NAMES.
# Pulling an image that is not fully qualified, i.e., one that includes the
# image name but does not include the registry or tag, is not recommended.
# There is a risk that the image being pulled could be spoofed. An example
# of this would be if a user wanted to pull an image named `foobar` from a
# registry and expect it to come from myregistry.com. If myregistry.com is
# not first in the search list, an attacker could place a different `foobar`
# image at a registry earlier in the search list. Now you would accidentally
# run the attackers code rather than the intended content. Registries that
# are added to this list should be completely controlled, i.e., not allow
# unknown/arbitrary users being able to create accounts with arbitrary names
# to prevent an image from being spoofed, squatted or otherwise made
# insecure. If it is necessary to use one of these registries, it should be
# added at the end of the list.
#
# It is recommended to use fully-qualified images for pulling as the
# destination registry is unambiguous. Pulling by digest
# (i.e., quay.io/repository/name@digest) further eliminates the ambiguity of
# tags.
[registries.search]
registries = ['registry.fedoraproject.org', 'registry.access.redhat.com', 'registry.centos.org', 'docker.io', 'quay.io']
registries = ['registry.fedoraproject.org', 'registry.access.redhat.com', 'registry.centos.org', 'docker.io']
# Registries that do not use TLS when pulling images or uses self-signed
# certificates.
@ -29,6 +50,7 @@ registries = []
# The second version of the configuration format allows to specify registry
# mirrors:
#
# NOTE: Please read the note about the risk of unqualified images identified above.
# # An array of host[:port] registries to try when pulling an unqualified image, in order.
# unqualified-search-registries = ["example.com"]
#

View File

@ -46,7 +46,7 @@ Epoch: 1
Epoch: 0
%endif
Version: 0.1.41
Release: 25.dev.git%{shortcommit0}%{?dist}
Release: 26.dev.git%{shortcommit0}%{?dist}
Summary: Inspect container images and repositories on registries
License: ASL 2.0
URL: %{git0}
@ -434,6 +434,10 @@ export GOPATH=%{buildroot}/%{gopath}:$(pwd)/vendor:%{gopath}
%{_datadir}/%{name}/test
%changelog
* Thu Feb 6 2019 Dan Walsh <dwalsh@fedoraproject.org> - 1:0.1.41-26.dev.git7cbb8ad
- Remove quay.io from list of search registries, removes risk of squatters.
- Update man pages to match upstream
* Thu Jan 30 2020 Fedora Release Engineering <releng@fedoraproject.org> - 1:0.1.41-25.dev.git7cbb8ad
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild