Connect Cloud Function and App Engine internally

1
votes

I have an arquitecture where a Cloud Function gets trigered whenever a file gets uploaded to a bucket and send the task to an API built on Flask and deployed on App Engine.

I want to make this process internal so that only the Cloud Function can access the App Engine endpoints, but I am struggling with the process.

As these two services are serverless, I can't just filter the traffic in the App Engine firewall since the Cloud Function will have a different IP each time a new instance is created.

I have tried to follow this guide, in which they recommend to associate all the function egress traffic to a Serverless VPC Connector asigned to a subnet, and then control all the traffic of that subnet with a NAT, assigning it a static IP address. This way I could filter on my App Engine firewall by the NAT IP, which will always be the same.

After following all the steps, I am still not able to filter the traffic. With this configuration done, if I open the traffic to everyone and print the IP routes given by the App Engine header X-Forwarded-For when I send a simple GET request from the Cloud Function, it returns the following 0.0.0.0, 169.254.1.1 (it is a list since this header records the clint IP and the proxies involved in the route). The static IP address assigned to my NAT is 34.78.XX.XX, so it seems that the function is not using the NAT to redirect the traffic.

I have read somewhere that when the destiny IP is hosted on Google Cloud, the traffic will not go through the NAT gateway, so maybe this solution won't work on my usecase.

Any idea what am I doing wrong, or if there exist any alternatives for making the process private?

1
pythongoogle-app-enginegoogle-cloud-platformgoogle-cloud-functions
Have you tried creating a Serverless VPC connector and connect them through that? – Gray_Rhino
@Gray_Rhino That's the approch I mentioned on the question. I will change VPC Connector to Serverless VPC Connector so that it is more clear, thank you. – Luiscri
That's the only way I can think off. Here's another tutorial that addresses your issue. It might be the same as what you have tried but give it a try. – Gray_Rhino
@Gray_Rhino That's the exact guide I used to create the architecture, but it did not work as expected. I tried to allow in my App Engine firewall the traffic comming from my Serverless VPC Connector subnet, but the traffic does not reach the App Engine using the IP range assigned to the subnet I don't know why. – Luiscri

1 Answers

2
votes

There are 2 solutions to solve this problem. And the choice depends on what you believe in!

Network based solution

If you want to keep your App Engine internal only, I means at network point of view, you can set the |ingress control to internal-only to accept only traffic coming from the VPC of your project

From there, you need to deploy your Cloud Functions, with a VPC connector (to route the traffic to the VPC) and set the egress control to All to route the traffic, public and private, to the VPC.

Indeed, even is you set your App Engine in ingress internal mode, the service is still publicly accessible, but there is an additional check on the request origin to be sure that it comes from the project VPCs. Therefore, when you call App Engine with your Cloud Functions, you call a public endpoint, and you need to route the public traffic to your VPC for being accept on App Engine internal only ingress.

This solution works only with VPC on the project. Cross project set up is impossible

Identity based solution

Google says: Don't trust the network

So, based on that, Google trust the identity of the traffic and request. You can keep your service private (not accessible by anyone except authorized access) only by controlling the authentication of the connection.

For that, you need to activate IAP on your App Engine service and to authorize only the service account of your Cloud Functions.

Then, in your cloud functions, you need to generate an identity token manually and to add it in the header of your request.

Be careful, there is a trap here. The audience is the IAP Client ID (that you can find in the APIs & Services -> Credential page)

Only the valid requests, checked by IAP, will trigger your App Engine service. In case of attacks, IAP will absorb the bad traffic, not App Engine.

So now, what do you trust?