search

openfaas / faasd

A lightweight & portable faas engine
https://store.openfaas.com/l/serverless-for-everyone-else
MIT License
2.98k stars 214 forks source link

Feature request: insecure HTTP registries #97

Closed fundef1 closed 4 years ago

fundef1 commented 4 years ago

Expected Behaviour

I have a non-standard setup:

i followed the hello-python guide.

Current Behaviour

faas-cli deploy -f .\hello-py.yml
Deploying: hello-py.
WARNING! Communication is not secure, please consider using HTTPS. Letsencrypt.org offers free SSL/TLS certificates.

Unexpected status: 400, message: unable to pull image faas-reg.lan:5000/hello-py:latest: cannot pull: failed to resolve reference "faas-reg.lan:5000/hello-py:latest": failed to do request: Head https://faas-reg.lan:5000/v2/hello-py/manifests/latest: http: server gave HTTP response to HTTPS client

Possible Solution

how do I / where do I / can I specify faas-reg as "insecure registry" for faasd?

faasd configuration setting similar to docker:

  "insecure-registries": [
    "faas-reg.lan:5000"
  ],
alexellis commented 4 years ago

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 https://github.com/containerd/containerd/issues/3847 and https://github.com/containerd/containerd/issues/2758 and https://github.com/containerd/cri/issues/559 seem to be related to your request.

Alex

alexellis commented 4 years ago

/set title: Feature request: insecure HTTP registries

fundef1 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

;-) 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 commented 4 years ago

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 commented 4 years ago

/add label: revisit

fundef1 commented 4 years ago

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 commented 4 years ago

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.

CleverCoder commented 1 year ago

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.