Add `--tls-verify` option for `docker login`

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/

{
  "insecure-registries" : ["myregistrydomain.com:5000"]
}

As an example, a tool in the same general area as docker is skopeo. This tool currently supports a --tls-verify option for skopeo login - and works as I would expect this potential new feature for docker login to work. During the performance of skopeo 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 as skopeo sync and skopeo 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 or docker 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:

> docker pull 127.0.0.1:5000/nginx:latest
WARNING: The registry "127.0.0.1:5000" was marked as insecure during docker login.
WARNING: Please ensure this registry is known to be insecure, and that this is expected.
latest: Pulling from library/nginx
b4d181a07f80: Pull complete 
66b1c490df3f: Pull complete 
d0f91ae9b44c: Pull complete 
baf987068537: Pull complete 
6bbc76cbebeb: Pull complete 
32b766478bc2: Pull complete 
Digest: sha256:8df46d7414eda82c2a8c9c50926545293811ae59f977825845dda7d558b4125b
Status: Downloaded newer image for nginx:latest
127.0.0.1:5000/library/nginx:latest

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 the daemon.json file itself. One marker for the daemon.json file to distinguish this could look like the following:

{
  "insecure-registries" : [
    "myregistrydomain.com:5000",
    "runtime:myotherregistrydomain.com:5000"
  ]
}

Output of docker version:

Docker version 20.10.7, build f0df350

Output of docker info:

Client:
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)
  compose: Docker Compose (Docker Inc., v2.0.0-beta.6)
  scan: Docker Scan (Docker Inc., v0.8.0)

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 20
 Server Version: 20.10.7
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: d71fcd7d8303cbf684402823e425e9dd2e99285d
 runc version: b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.10.25-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 3.844GiB
 Name: docker-desktop
 ID: 6TAU:Y375:2HDP:VAPH:36OD:VAVK:D4XR:PHAK:PNE6:4YQ6:LDLK:OXEK
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.1:5000
  test.localdomain:1234
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):

MacOS Big Sur v11.4

Start with the docker login command and review how daemon.json currently supplies insecure registries. Compare the requested behavior with skopeo's --tls-verify option, then resolve the security and persistence concerns raised in the issue. Done means the runtime option's behavior, warnings, and interaction with daemon configuration are defined and covered by appropriate tests.