Give the option to prevent functions being invoked by their public URL

[DriesCruyskens]

My actions before raising this issue

• Followed the troubleshooting guide
• Read/searched the docs
• Searched past issues

Why do you need this?

Some functions should not be able to get triggered by an HTTP request. In my case it concerns scheduled functions (cron-connector) that should only run once a day. Unless I am mistaken, every function is callable using their public url. This makes functions susceptible to being called on accident or even by bots.

Expected Behaviour

Functions should have the option of being callable by public URL or not.

Current Behaviour

Every function gets assigned a public URL.

Are you a GitHub Sponsor (Yes/No?)

Check at: https://github.com/sponsors/openfaas

• Yes
• No, but owner of Serverless for Everyone Else

List All Possible Solutions and Workarounds

1. Add yaml entry that disables a functions public URL.

2. Have a way to discern between event-connectors IN the function. Say using an environment variable. This way the function can return early when it detects it's being invoked in the wrong way.

3. Find a workaround and add it to the documentation.

Which Solution Do You Recommend?

1. Add yaml entry that disables a functions public URL.

Steps to Reproduce (for bugs)

n/a

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ): 0.14.2

• Docker version docker version (e.g. Docker 17.0.05 ): Docker version 20.10.10, build b485636

• Are you using OpenFaaS on Kubernetes or faasd? faasd

• Operating System and version (e.g. Linux, Windows, MacOS): MacOS 12.3.1, m1 Macbook Pro

• Code example or link to GitHub repo or gist to reproduce problem:

• Other diagnostic information / logs from troubleshooting guide

[alexellis]

Hi,

Thanks for leaving the context about what you're trying to do.

Unfortunately, you deleted important parts of the issue template, so I'd ask you to add those back in now.

https://raw.githubusercontent.com/openfaas/faas/master/.github/ISSUE_TEMPLATE.md

Alex

[DriesCruyskens]

Thanks for taking the time to reply, I added them back in. Let me know if you need more clarification.

[alexellis]

Hi @DriesCruyskens

We recommend using authentication for functions which are sensitive.

There is no practical way to hide functions on the OpenFaaS gateway, since it is the only way that we recommend to access a function, whether you consider it private or public.

So, that brings me on to my preferred solution at present.

Wherever possible, always use authentication - shared secrets, OAuth clients, etc.

For when you have functions that are called by the cron-connector, it has no way to send authentication, therefore, I would suggest you hide the gateway from the Internet completely.

Then just expose what you want the Internet to access.

You can create an Ingress record for a domain and one TLS cert for each of them or for a specific path on a single domain and only use one TLS cert for all of them.

We have provided FunctionIngress for you to achieve this: https://docs.openfaas.com/reference/ssl/kubernetes-with-cert-manager/#20-tls-and-custom-domains-for-functions

• blog is remapped to blog.example.com and has a mixture of anonymous authentication and OAuth2 for the admin page, it must be public
• github-events receives webhooks, and does HMAC authentication before processing events, but must be public.
• invoice-customers is called daily, and checks for customers who need an invoice then emails them. It would not be an issue if it was called externally, however it could generate more emails than we want. The Cron Connector calls it and has direct access to the Internet. The gateway is not exposed on the Internet, and therefore external users cannot invoke this function.

If you need to do deploys to the gateway, you can open up another HTTP Path / Route or custom domain and just allow the /system/ endpoint to be exposed there.

The same concepts work with faasd, using Caddy and the examples written in Serverless for Everyone Else

I'll close this issue as resolved / as designed, however feel free to keep the discussion going.

Regards,

Alex