Feature request: insecure HTTP registries about faasd

[CleverCoder]

This is still a relevant issue. Following the documentation here: https://docs.openfaas.com/tutorials/local-kind-registry/
The resolved URL for the registry is something like: https://localhost:5001/v2/<function>/manifests/latest
When the faas CLI tries to deploy, I see an error:

dial tcp [::1]:5001: connect: connection refused

However, the image is fine and the URL works when switching https to http.
This seems like a pretty common use-case. As far as the "incorrect behavior" comment, it's much easier to not have to fiddle with TLS when developing locally, so I have to disagree.

[alexellis]

Hi,

On the whole we haven't spent any time on supporting insecure workflows, but "secure" workflows with TLS work seamlessly if you wanted to try that instead?

So the short answer is that I'm not sure (immediately) how you can force faasd into doing the wrong thing, but you can setup a valid TLS cert for your private registry in a few ways:

1. Put it on the Internet with inlets (long way) or with inlets PRO (quick way) and get a TLS cert using LetsEncrypt (example -> https://docs.inlets.dev/#/get-started/quickstart-caddy)
2. Keep it private, and get a TLS cert from LetsEncrypt using Caddy and a DNS01 challenge where you create a DNS entry corresponding to the IP of faas-reg.lan
3. Follow a complete tutorial and host your registry on a small VM with k3s: https://blog.alexellis.io/get-a-tls-enabled-docker-registry-in-5-minutes/
4. Add a self-signed CA / cert to your registry, and add the cert to the trust store of your faasd VM -> https://docs.docker.com/registry/insecure/#use-self-signed-certificates

Forcing faasd to use an insecure registry will probably take a PR or further research into containerd. Have you looked in the containerd issue tracker yet? I see containerd/containerd#3847 and containerd/containerd#2758 and containerd/cri#559 seem to be related to your request.

Alex

[alexellis]

/set title: Feature request: insecure HTTP registries

[fundef1]

Hi, thanks for the quick reply and suggestions on how to move forward.
I'll probably follow the self-signed certificate route as that's easiest and most familiar to me.

since I asked this question i looked into containerd and found two inroads:

1. containerd allows http for registries via:

        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."faas-reg.lan"]
          endpoint = ["http://faas-reg.lan:5000"]

but I couldn't get that to work

containerd ctr command does support http through the plain-http switch.

ctr image pull faas-reg.lan:5000/hello-py:latest --plain-http

so I now have the image on 'faasd' but not sure how to run it (without screwing up faasd)

ctr image ls -q
docker.io/library/nats-streaming:0.11.2
docker.io/openfaas/basic-auth-plugin:0.18.17
docker.io/openfaas/gateway:0.18.17
docker.io/openfaas/queue-worker:0.11.2
docker.io/prom/prometheus:v2.14.0
faas-reg.lan:5000/hello-py:latest

maybe this helps in implementing this, a --plain-http switch for faas-cli maybe?

[alexellis]

I don't think that there's an issue with faas-cli.

You can try hacking on the Go code here https://github.com/openfaas/faasd/blob/master/pkg/service/service.go

Do you know where it fails in the code?

[fundef1]

Sorry if I wasn't clear. The behaviour so far is correct - faas-cli correctly catches/reports on the "expected HTTPS get HTTP".

I'm not clear on whether it is faas-cli attempting to pull the manifest, or whether it is directing faasd to pull the manifest and faas-cli is simply reporting the error from faasd.
I'm not at all familiar with go. I couldn't determine at which point faas-cli/faasd chooses https over http - or maybe directs ctr/containerd to pull the image over https....

so far, I haven't yet managed to run a function on faasd yet, I'll get that running before I start messing with Go. ;-)

[alexellis]

so far, I haven't yet managed to run a function on faasd yet

That's entirely your choice though. My advise is to use a secure public registry or apply TLS with one of the 4-5 methods given above.

[fundef1]

;-) Yes, yes, definetly not criticizing faasd. - I'm going to go the self-signed cert route.

I was only saying I'm going to try that first, try to get something up and running, before opening up a whole new rabbit hole messing with a language I don't know, in an ecosystem of faasd/faas-cli/docker-registry/containerd that I don't know.

[alexellis]

I'm going to close this one out for now. It doesn't mean a hard no, it just means it's not top priority at the moment and that we've provided valid alternatives. Folks can comment here if it's important for their commercial use of faasd etc.

For further support around this consider the Docker/K8s/OpenFaaS slack workspaces.

[alexellis]

/add label: revisit

[fundef1]

I totally agree.
generating and installing a self-signed cert took less than 15 mins - the only thing that caught me out that faasd didn't pick up on it. a restart fixed that.
thanks for your help - I've got it up and running

[ABVitaliAUSY]

Hi, thanks for the quick reply and suggestions on how to move forward.
I'll probably follow the self-signed certificate route as that's easiest and most familiar to me.

since I asked this question i looked into containerd and found two inroads:

1. containerd allows http for registries via:

        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."faas-reg.lan"]
          endpoint = ["http://faas-reg.lan:5000"]

but I couldn't get that to work

containerd ctr command does support http through the plain-http switch.

ctr image pull faas-reg.lan:5000/hello-py:latest --plain-http

so I now have the image on 'faasd' but not sure how to run it (without screwing up faasd)

ctr image ls -q
docker.io/library/nats-streaming:0.11.2
docker.io/openfaas/basic-auth-plugin:0.18.17
docker.io/openfaas/gateway:0.18.17
docker.io/openfaas/queue-worker:0.11.2
docker.io/prom/prometheus:v2.14.0
faas-reg.lan:5000/hello-py:latest

maybe this helps in implementing this, a --plain-http switch for faas-cli maybe?

I came up on this issue thanks to Alex Ellis link to containerd issues.
Even if we all agree on the fact that we should not support "too much" incorrect behavior, I think I found the right config you should place for containerd. I don't know at all if there is any peculiarity related to faas so maybe it doesn't solve your issue @fundef1, but you can give it a try.

The config you are looking for to do the equivalent of "insecure-registries" in daemon.json for docker is:

[plugins."io.containerd.grpc.v1.cri".registry.configs."faas-reg.lan"]
   [plugins."io.containerd.grpc.v1.cri".registry.configs."faas-reg.lan".tls]
      insecure_skip_verify = true

Hope that it could help, let me know if you have the chance.