S3 driver should support Insecure TLS

[pdevine]

The S3 driver currently has the "secure" option which will turn off TLS, however there is currently no option for using TLS but with an untrusted cert.

This prevents alternative S3 storage such as Minio, Scality and StorageGRID from running encrypted but with an invalid cert.

[dmcgowan]

This prevents alternative S3 storage such as Minio, Scality and StorageGRID from running encrypted but with an invalid cert.

Does not prevent it, just currently requires that such solutions trust the certificate at the OS level.

I would be OK with a PR to add an option to use a custom certificate chain, could be added via the http transport like the user agent is doing (https://github.com/docker/distribution/blob/master/registry/storage/driver/s3-aws/s3.go#L418)

[whoshuu]

What about a PR adding an option to set InsecureSkipVerify (like it's done here) on the transport? That would obviate the need to provide an interface for custom certificates that exist outside of the OS.

[dmcgowan]

@whoshuu I don't like adding support for InsecureSkipVerify except for clearly defined development use cases. For registry development there are already plenty of other storage configurations which can be used. For real setups we should always encourage properly setting up TLS, it really isn't much extra work but makes a huge difference is security.

[whoshuu]

It's strictly more secure than Secure: false, which is already an option.

The ideal solution would be for every user to know how to properly set up certs on their clients and servers. Understandably that can be difficult for some class of users.

An option to skip the verification step of the server certificate isn't one we would encourage, obviously. There should definitely be a strong push to get users to set up true TLS, but for getting things up and running without sending unencrypted data over the network I think this is a fair compromise.

@pdevine, thoughts?

[pdevine]

@whoshuu definitely agree. I think we should add InsecureSkipVerify and also strongly discourage its use.

Some storage, like StorageGRID comes with a baked in CA, and it's impossible to use it with distribution right now, even to test, without having to bake the CA cert or the cert chain into your distribution container image.

[kaovilai]

@dmcgowan

I would be OK with a PR to add an option to use a custom certificate chain, could be added via the http transport like the user agent is doing

Like this?
#3734

[milosgajdos]

Closing. Addressed in #3841