-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add --tls-verify
option for docker login
#3183
Comments
This is (roughly) a duplicate of moby/moby#8887 Adding this flag to
Yes, it does. Disabling TLS verify definitely affects security; a user could now Of course, there may be situations where "insecure" is considered "OK" (depending on the situation; e.g., test-environments, and registry running within an internal network); Note that loopback IP addresses are already marked as "insecure" by default ( If the ephemeral registries are on an internal network, it's possible to specify the internal ip-range as "insecure". Or, if you like to live dangerous; specify the whole internet as "insecure", which would be the rough equivalent of fully disabling TLS protection moby/moby#8887 (comment) {"insecure-registries": ["0.0.0.0/1","128.0.0.0/2","192.0.0.0/3","224.0.0.0/4"]} |
This is good information - although I am still on the side of the fence that supporting some method of runtime marking would be ideal. The main idea being that during automated setup of certain environments which already expect insecure registries to be marked, we could have My main question is - would the benefits of this type of feature outweigh any possible security concerns? Given that other tools ( |
I think one big difference between For that reason, the configuration is currently on the daemon side; the person responsible for managing the daemon controls wether or not connecting with insecure registries should be allowed. |
Would it be worth exploring an additional Potentially, a sub-command could be created to document and template any settings that are supported within the Just spitballing at this point, it's not the end of the world if this never comes to fruition. But I know that many heavily automated shops would leverage these types of features very quickly if implemented. |
Description
The
docker login
command should ideally support a new--tls-verify
option for marking insecure registries at runtime.Current methodology:
Currently, any insecure registries must be added to the
daemon.json
file, and docker must be restarted to reflect changes. This works well for long-term registry usage on long-living machines, but this current feature-set could be extended to better support more ephemeral environments by removing manual configuration steps for marking insecure registries.IE - https://docs.docker.com/registry/insecure/
As an example, a tool in the same general area as
docker
isskopeo
. This tool currently supports a--tls-verify
option forskopeo login
- and works as I would expect this potential new feature fordocker login
to work. During the performance ofskopeo login
, authentication credentials are stored along with a mark for the registry being "insecure", further use of this registry does not require valid CA trust for commands such asskopeo sync
andskopeo copy
.IE - https://github.com/containers/skopeo/blob/main/docs/skopeo-login.1.md
Generally, when a user is logging into a registry - they have at least a basic understanding of the details of that registry, whether it be self hosted, upstream, etc. We should extend support for the user to mark this registry as "insecure" during the login action to help remove manual configuration steps on their end, as many users may overlook this manual action as a pre-configuration step during internal tool usage. This creates confusion in heavily automated environments, and removing this step would go a long way in easing the use of the docker cli.
Possible concerns:
Does this create a security regression concern? Should we be worried about this potentially being exploited in upstream and publicly available configuration scripts if implemented? As a potential solution, we could add output for
docker pull
ordocker run
to make it know to the user that the current registry is insecure, so at least some awareness is provided throughout its use. This could be extended to any potential log files in use as well.For example, this output could look like this:
The above warning could potentially trigger only if a registry was marked as insecure during
docker login
, which would distinguish this potentially insecure action from registries that were marked as insecure within thedaemon.json
file itself. One marker for thedaemon.json
file to distinguish this could look like the following:Output of
docker version
:Output of
docker info
:Additional environment details (AWS, VirtualBox, physical, etc.):
MacOS Big Sur v11.4
The text was updated successfully, but these errors were encountered: