Cloud Endpoints to trigger Cloud Functions

[Aidan Hoolachan]

Have there been suggestions from Google about providing support for triggering Cloud Functions directly from Cloud Endpoint calls? This seems to be the logical next step for the platform. As far as I can tell., there isn't currently a GCP configuration that supports/mimics this paradigm. I consider the main value add to be Auth piped into the Function context.

[Sepehr Ebrahimzadeh]

Hi Aidan, 

You're correct: this is something that we're working on but is not currently supported. Are you already using Cloud Functions extensively?

Would you please tell us more (on this thread or privately) about your use cases?

Thanks,

Sepehr

On Thu, Apr 6, 2017 at 7:30 PM, Aidan Hoolachan <aidan.h...@gmail.com> wrote:

Have there been suggestions from Google about providing support for triggering Cloud Functions directly from Cloud Endpoint calls? This seems to be the logical next step for the platform. As far as I can tell., there isn't currently a GCP configuration that supports/mimics this paradigm. I consider the main value add to be Auth piped into the Function context.

--
You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endpoints+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/388a6f35-5fb3-49ac-a8f0-4766e1bfd200%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[aco...@gmail.com]

+1. I have been writing all the API implementations with Functions, now I only need the API endpoints to wire them up.

[je...@opinulate.com]

+1, same use case – basically, playing with the idea of building most/all of an API server via Functions. Other than the beta nature of Functions and inherent FaaS deployment/ops challenges, is this a bad idea? 

What alternatives are people using? App Engine to house all the endpoint logic, with heavy lifting in Functions and probably some PubSub seems like the obvious alternative, but I'm pretty new to GCP ecology.

[ismail...@gmail.com]

+1 would love to see this.

AWS already does something similar, I believe...

[ism...@humbike.com]

It's been 9 months, is there any progress on this front?

[awa...@gmail.com]

+1

[ozair...@gmail.com]

+1

[Doug Tangren]

On Jan 19, 2018 5:13 AM, <ozair...@gmail.com> wrote:

+1

+1 it's been about that for a number of trials that we're announced back then. Multi region support and others. Do we think we'll see a GA announcement this year?

On Friday, April 7, 2017 at 7:30:51 AM UTC+5, Aidan Hoolachan wrote:

Have there been suggestions from Google about providing support for triggering Cloud Functions directly from Cloud Endpoint calls? This seems to be the logical next step for the platform. As far as I can tell., there isn't currently a GCP configuration that supports/mimics this paradigm. I consider the main value add to be Auth piped into the Function context.

--

You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endpoints+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/f008e8db-0b1d-49c4-bd95-b069b1517e92%40googlegroups.com.

[Jeremy Lorino]

Is this suggestion basically and API gateway in front of Cloud Funcs?

[armstead...@principal.com]

+1

[dcdh...@gmail.com]

This is a pretty major flaw IMO, Cloud Functions should be treated as first-class citizens in newly-released services.

[Dan Ciruli]

Hi, all -- we are glad to see people chiming in on this thread and very excited to see the desire to have these two products working together.

We are working on a solution that we think you'll like a lot. There is a bit of an architecture change to make it happen (given that Cloud Endpoints currently uses a server-side proxy, and Cloud Functions is a serverless environment). But we've got a solution to that in mind.

Unfortunately, I don't have a date that I can speak about publicly. However, as soon as we are ready for users, you will be the first to know.

DC

On Tue, Jan 30, 2018 at 7:00 AM, <dcdh...@gmail.com> wrote:

This is a pretty major flaw IMO, Cloud Functions should be treated as first-class citizens in newly-released services.

--

You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endpoints+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/096243a0-e190-4973-b984-2f6c22c9f6c9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

DC

[dcdh...@gmail.com]

That's great. There's a lot of interest in this sort of functionality within my company, and I'll definitely be an early adopter personally.

[Jeremy Lorino]

Yo Dan, I assume this is when y'all will begin leveraging Firebase rule sets that exist in Firebase/Firestore and applying them to ESP?

I want my Firestore Rules to govern Endpoints Authz and not manage multiple rule sets.

Please and thank you. ;)

[625...@gmail.com]

+1

[jmsg...@gmail.com]

+1

[thetom...@gmail.com]

I'd also like to see this! +1

[t...@factoryfix.com]

+1

On Thursday, April 6, 2017 at 9:30:51 PM UTC-5, Aidan Hoolachan wrote:

[donati...@gmail.com]

+1 

[an...@marketcheck.com]

+1

[razvan....@linnify.com]

+1

[leonardoviv...@gmail.com]

+1

Em quinta-feira, 6 de abril de 2017 23:30:51 UTC-3, Aidan Hoolachan escreveu:

[Lukas Karlsson]

I'm confused about what exactly is not supported here. 

I am able to setup a Cloud Function that is triggered via HTTP and I am able to have one of my Cloud Endpoints apps running in App Engine Standard on Python to use urlfetch to hit a web URL.

What specifically is it about the relationship between Google Cloud Endpoints and Google Cloud Functions that makes it so you can not trigger an HTTP Cloud Function from a Cloud Endpoints application?

/l

On Fri, Apr 7, 2017 at 12:24 PM 'Sepehr Ebrahimzadeh' via Google Cloud Endpoints <google-clou...@googlegroups.com> wrote:

Hi Aidan, 

You're correct: this is something that we're working on but is not currently supported. Are you already using Cloud Functions extensively?

Would you please tell us more (on this thread or privately) about your use cases?

Thanks,

Sepehr

On Thu, Apr 6, 2017 at 7:30 PM, Aidan Hoolachan <aidan.h...@gmail.com> wrote:

Have there been suggestions from Google about providing support for triggering Cloud Functions directly from Cloud Endpoint calls? This seems to be the logical next step for the platform. As far as I can tell., there isn't currently a GCP configuration that supports/mimics this paradigm. I consider the main value add to be Auth piped into the Function context.

--
You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/388a6f35-5fb3-49ac-a8f0-4766e1bfd200%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/CAASa8TZTd10dMt0ze1cBG4EMgn645syxHp3viu5gM2zPnAUeYw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Lukas Karlsson, Cloud Architect / Developer Advocate

Broad Institute of MIT and Harvard
75 Ames Street, 11129, Cambridge, Massachusetts 02142
karl...@broadinstitute.org, +1.6177147142

[Lukas Karlsson]

Meaning, if I am able to trigger my cloud function by running curl on my local machine, why can't it be triggered from an app running in App Engine with Cloud Endpoints?

/l

[timot...@gmail.com]

The idea is to set up a cloud function as an endpoint node, rather than accessing it from code running at an endpoint node running on Compute. Dispatch would route directly to the function.

[Lukas Karlsson]

Ah, so folks want to remove the App Engine app and have the Endpoints from the Cloud Functions instead.  Got it.

/l

On Sun, Jun 10, 2018 at 11:39 AM <timot...@gmail.com> wrote:

The idea is to set up a cloud function as an endpoint node, rather than accessing it from code running at an endpoint node running on Compute. Dispatch would route directly to the function.

--
You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/7fac11f4-8c10-437e-955d-e61a4cc266a6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[in...@optimalisatie.nl]

+1

It may be possible using ESP (Extensible Service Proxy). It is basically a custom Nginx server that could use LUA and subrequests to trigger a cloud function.

https://github.com/cloudendpoints/esp

[in...@optimalisatie.nl]

Example Nginx upstream for Google Cloud Function:

# google cloud optimization function
upstream o10n-function {
    server us-central1-xxx-1234.cloudfunctions.net:443;
}

You then simply use the proxy_pass method to trigger the function:

# optimization function
location /o10n-function/ {
    allow 127.0.0.1;
    deny all;


    proxy_pass https://o10n-function/o10n-html;
}

Op maandag 9 juli 2018 14:28:07 UTC+2 schreef in...@optimalisatie.nl:

[Rose Davidson]

The problem with this scenario is that the cloud function is still accessible by hitting its direct URL; there is (as far as I know) no way to enforce that access happens only through the proxy.

--

You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/a58c3ad9-9bae-40de-8448-5f4baea6abfe%40googlegroups.com.

[in...@optimalisatie.nl]

The ESP / Nginx proxy can add a header to identify requests. It will then be simple to block requests without the header.

Nginx also provides rate limiting and anti-DDoS functionality, this may help to prevent/reduce costs by potential abuse.

https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/

In regards to more advanced authentication, for example blocking requests without valid authentication, you could extend Nginx using Lua and subrequests which makes it possible to use Google's authentication service API or to perform authentication within the ESP server. The ability to limit traffic to the cloud function will help to reduce costs.

In regards to performance, CloudFlare is built using Nginx + Lua. It supports C++ code so it can be made efficient and reliable.

https://blog.cloudflare.com/pushing-nginx-to-its-limit-with-lua/

[de...@broadinstitute.org]

It seems like in this scenario (ESP as Nginx proxy for CFs) we lose crucial benefits of ESP, e.g. checking authentication and request validation, because there's no way to enforce that traffic to CFs only comes from ESP.

[Timothy Nott]

Can't one require the X-Endpoint-API-UserInfo header? While I think that could be a work-around, what we need is for ESP to stand in front of cloud functions in the same way that it does for app engine and use dispatch rules to direct traffic.

--
You received this message because you are subscribed to a topic in the Google Groups "Google Cloud Endpoints" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-cloud-endpoints/gwmuJNEgfAI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-cloud-endpoints+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/5d02163f-c882-4814-a799-f59f19b0b706%40googlegroups.com.

[Denis Loginov]

What could be possible is to sign the entire validated request with a SA key, forward the request with signature to CF, and verify the signature in CF. Then there's guarantee the request has come from ESP. The main problem with this approach is additional latency (on top of having to run a container behind ESP just to sign the requests).

The "light" version could verify only token signature (and thus only needs a bare-bones ESP for request validation), but then there's possibility that someone could have bypassed ESP if they stole a token and forged the request.

On Tue, Jul 10, 2018, 11:41 AM Timothy Nott <t...@factoryfix.com> wrote:

Can't one require the X-Endpoint-API-UserInfo header? While I think that could be a work-around, what we need is for ESP to stand in front of cloud functions in the same way that it does for app engine and use dispatch rules to direct traffic.

On Tue, Jul 10, 2018 at 10:28 AM, <de...@broadinstitute.org> wrote:

It seems like in this scenario (ESP as Nginx proxy for CFs) we lose crucial benefits of ESP, e.g. checking authentication and request validation, because there's no way to enforce that traffic to CFs only comes from ESP.

On Monday, July 9, 2018 at 5:22:41 PM UTC-4, in...@optimalisatie.nl wrote:

The ESP / Nginx proxy can add a header to identify requests. It will then be simple to block requests without the header.

Nginx also provides rate limiting and anti-DDoS functionality, this may help to prevent/reduce costs by potential abuse.

https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/

In regards to more advanced authentication, for example blocking requests without valid authentication, you could extend Nginx using Lua and subrequests which makes it possible to use Google's authentication service API or to perform authentication within the ESP server. The ability to limit traffic to the cloud function will help to reduce costs.

In regards to performance, CloudFlare is built using Nginx + Lua. It supports C++ code so it can be made efficient and reliable.

https://blog.cloudflare.com/pushing-nginx-to-its-limit-with-lua/

--
You received this message because you are subscribed to a topic in the Google Groups "Google Cloud Endpoints" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-cloud-endpoints/gwmuJNEgfAI/unsubscribe.

To unsubscribe from this group and all its topics, send an email to google-cloud-endp...@googlegroups.com.

[Denis Loginov]

The earlier idea of adding a secret header in ESP/Nginx and verifying it in CF also has some appeal, however it implies the 2 runtimes either must store a pre-shared secret (which would lower security guarantees of temporary tokens), or forward hard-to-guess identifiers, again lowering security.

At the end of the day, this is about having a completely serverless system - running even just ESP on managed instances (incl. AppEngine) already defeats the purpose, because it requires more setup and keep-up.

It'd be really great to have this built into CF runtimes out of the box.

[gr...@carthew.net]

+1

[sudeepku...@gmail.com]

+1

[Bastian D]

+1

[Harrison Kelly]

+1

This functionality would make serverless with GCP a lot more intuitive and appealing. My platform of choice is GCP, but I'm dragging my feet on implementing a new feature with serverless because I don't want to deal with the workarounds.

[mat...@doton.co.uk]

+1 this would make our infrastructure much simpler

[ronzan...@gmail.com]

+1

[Terri Chu]

+1

[richi...@gmail.com]

+1

[christia...@gmail.com]

+1

[abhishek...@corecompete.com]

+1

[Wilson Tam]

+1

[sebastie...@gmail.com]

+1

[huye...@gmail.com]

+1

[cavas...@gmail.com]

+1

[thibault...@carrefour.com]

+1

On Thursday, February 21, 2019 at 11:52:51 PM UTC+1, cavas...@gmail.com wrote:

+1

[normanko...@gmail.com]

Hi, seems the problem still not resolved after almost 2 years. Is the roadmap to support Endpoint on GCF already deadend?

I am evaluating the product feature amongst various cloud provider and seems the progress on gcp is quite slow on this.

Aidan Hoolachan於 2017年4月7日星期五 UTC+8上午10時30分51秒寫道：

[Mike McDonald]

Hey folks,

I just started an EAP for this functionality: if you're interested, please fill out this survey and I'll add you to the group and let you play with it.

Thanks,

--Mike

[arsa...@gmail.com]

+1
Just filled out the form. Looking forward to using this functionality that’s been missing for years!

[mver...@kunder.cl]

Just filled out the survey, looking forward to testing this functionality. Thanks!

[Mike McDonald]

The docs are public, so feel free to start using it now!

https://cloud.google.com/endpoints/docs/openapi/get-started-cloud-functions

https://cloud.google.com/endpoints/docs/openapi/get-started-cloud-run

Thanks,

--Mike

--
You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/6bd82ff8-e84f-449b-aaac-c64e19643077%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Michael McDonald | Product Manager, Serverless | mpmcd...@google.com | 1-844-THE-FIRE