Support private Docker registry about faas

[alexellis]

Hi @sebgl - this request makes sense and I'd like to support private registries.

Questions:

• Can swarm secrets replace the plaintext environmental variables?

• Could you have to support multiple private registries at once? If that were the case how would that be possible with the proposal?

• Do you have a 1-liner to start a private registry with username/password enabled (TLS?)

• Could the existing credentials store be used instead? ~/.docker/config.json

https://github.com/moby/moby/blob/69c35dad8e7ec21de32d42b9dd606d3416ae1566/docs/reference/commandline/login.md#credentials-store

https://github.com/docker/cli/blob/6686ada6a4cf4e872af4d9bf3f61c387be934d87/cli/config/credentials/native_store.go#L60

https://github.com/docker/cli/blob/dee8e6ab2da3fe1f57f57de6c009a9256040d1d0/cli/command/cli.go#L110

[sebgl]

Hi @alexellis , thanks for the quick answer.

My use case (having only one single registry) is a tiny subcase of the more general one.
Since this might interest you: we're basically adding another API in front of the gateway to handle authentication, permissions, etc. This API is also responsible for building and pushing docker images, since we want users to give us code, not docker images. Hence we only need one private registry (ours, not the user's one). For now this is just a prototype, for fun :)

You're right in all questions that this should be handled in a more general way in FaaS gateway.

• Multiple private registries
  Yes ! Should this be a fixed list of allowed registries? Or should users be able to "add" access to new registries whenever they want via the gateway API (can play nice with registry permissions)? The latter seems more interesting but also a bit more complex to handle. I love how small and simple the codebase of FaaS is.

• Credential store & swarm secrets
  Indeed, environment variables do not seem right. Unless I have misunderstood something, we need all deployed gateways to be in possession of all registry secrets, so that they can pass the appropriate one (based on the docker image name prefix) to the swarm service create API.
  Best choice seems to store registries credentials as swarm secrets available from all deployed gateways. Could be as a /run/secrets/config.json file store. I'm just a bit concerned about updating this file if registries can be added/removed at runtime as discussed above.

Another way of handling both points above could be to allow users to provide registry credentials as a parameter in POST /system/functions: then we don't need to store credentials at all. What do you think?

• 1-liner to start a private registry
  That's not exactly one line, but I've set up this gist with instructions: https://gist.github.com/sebgl/3c97c379ddc77c65c44d47e6b745fa10
  Easiest way I found is to spawn a VM somewhere with DNS registered and port 443 open to the world for LetsEncrypt certificates generation, then run the docker-compose file as described in the gist.
  Running with self-signed certificates on localhost with swarm involves more tricks.

[alexellis]

What are you calling your API for building Docker images from code? it sounds like it has overlap with the FaaS CLI - https://github.com/alexellis/faas-cli

Are we already connected on Twitter or Linked in? If you can send me your email address I'll invite you the slack community where we're collaborating around FaaS.

I recently moved the UI under the /ui/ prefix, so that for security you could effectively keep /ui and /system within a blacklist and just expose /function via reverse proxy.

Who are you working with when you say we?

[sebgl]

Let's discuss it on Slack :)

[alexellis]

Fixed by #87