search

eth-cscs / sarus

OCI-compatible engine to deploy Linux containers on HPC environments.
https://sarus.readthedocs.io/en/stable/
BSD 3-Clause "New" or "Revised" License
129 stars 10 forks source link

support for insecure registries #23

Closed tdhooks closed 2 years ago

tdhooks commented 3 years ago

Currently, when attempting to pull from an insecure registry, the pull fails like so:

tdhooks@pop-os:~$ sarus pull localhost:5000/sarus/alpine:latest
# image            : localhost:5000/sarus/alpine:latest
# cache directory  : "/home/tdhooks/.sarus/cache"
# temp directory   : "/tmp"
# images directory : "/home/tdhooks/.sarus/images"
[1674.682032881] [pop-os-30306] [main] [ERROR] Error trace (most nested error last):
#0   retrieveImageManifest at "Puller.cpp":324 Error while sending request for manifest to remote registry
#1   "unknown function" at "unknown file":-1 Error in SSL handshake

Having skimmed through Puller.cpp, it looks like sarus is hard-coded to only support pulls from registries with valid https (see Puller.cpp:549).

Docker allows use of insecure registries mainly through the insecure-registry config field in /etc/docker/daemon.json, and this is very useful for those that want to use LAN secured registries without certs or simply for testing. Could/Should this be a new feature, configurable through a similar field in sarus.json or a sarus pull --insecure flag?

Note: I tested this with un-certed localhost and non-localhost repositories to the same result. I haven't tested with a self-signed certificate, however I suspect that will fail as well if not with the same error.

taliaga commented 3 years ago

Hi, that's right, the puller is just supporting pulls with https and validated certificates. And that should remain as the default behavior IMHO.

As you say, this could be a new feature useful for testing. Probably also the puller would have to include a client_config object in the client construction lines and use it to disable certificate validation only for those particular registries.

I would discourage the idea of the --insecure flag to the CLI because this could open significant security risks for the most common workflows. I think having an insecure-registries array in the sarus.json a-la-docker (or podman) that the puller can use as an "exceptional list or registries to retry without certificate validation" would be more interesting. This way, the security risks are a bit more under control of the system administrator (the only capable of touching sarus.json).

tdhooks commented 3 years ago

Totally agree that secure should be the default, and also that keeping the feature at the config/machine/admin level is the right implementation.

See #24

Madeeks commented 2 years ago

Fixed by #24