0

The current setup is as follows: I have a Cloud Run service, which acts as "back-end", which needs to reach external services but wants to be reached ONLY by the second Cloud Run instance. which acts as a "front-end", which needs to reach auth0 and the "back-end" and be reached by any client with a browser. I recognize that the setup is not optimal, but I've inherited as is and we cannot migrate to another solution (maybe k8n). I'm trying to make this work with the least amount of impact on the infrastructure and, ideally, without having to touch the services themselves.

What I've tried is to restrict the ingress of the back-end service to INTERNAL and place two serverless VPC connectors (one per service), so that the front-end service would be able to reach the back-end but no one else could.

But I've encountered a huge issue: if I set the egress of the front-end all on the VPC it works, but now the front-end cannot reach auth0 and therefore the users cannot authenticate. If I place the egress as "mixed" (only internal ip ranges go through the VPC) the Google Run URL (*.run.app) is resolved not through the VPC and therefore it returns a big bad 403.

What I tried so far:

  1. Placing a load balancer in front of the back-end service. But the serverless NEG only supports the global http load balancer and I'd need an internal one if I wanted an internal ip to resolve against
  2. Trying to see if the VPC accessor itself MAYBE provided an internal (static) ip, but it doesn't seem so
  3. Someone in another question suggested a "MIG as a proxy" but I haven't managed to figure that out (Can I run Cloud Run applications on a private IP (inside dedicated VPC network)?)
  4. Fooled around with the Gateway API, but it seems that I'd have to provide a openAPI specification for the back-end, and I'm still under the delusion that this might be resolved with a cheaper (in terms of effort) approach.

So, I get that the Cloud Run instance cannot possibly have an internal IP by itself, but is there any kind of GCP product that can act as a proxy? Can someone elaborate on the "MIG as a proxy" approach (Managed Instance Group? Of what, though?), which might be the solution I'm looking for? (Sadly, I do not have the reputation needed to comment on that question or I would have).

Any kind of pointer is, as always, deeply appreciated.

Menghini Luca
  • 1
  • 3
  • What do you mean by the front can't reach auth0 when the egress is set to all? Do you change the default route of the VPC? do you access other public URL in that configuration (other that Auth0)? – guillaume blaquiere Mar 29 '22 at 16:50
  • I meant to say that I set the egress traffic to ALL pass through the VPC. And no, auth0 would be the only external service I need to access. – Menghini Luca Mar 30 '22 at 06:25
  • Ok, did you change your VPC configuration, especially the routes? – guillaume blaquiere Mar 30 '22 at 07:33
  • I did not change the VPC configuration, and I've been using the default one because earlier attempts with a new one weren't working. I later learned that `Except for the default network, you must explicitly create higher priority ingress firewall rules to allow instances to communicate with one another` (https://cloud.google.com/vpc/docs/vpc#intra_vpc_reqs) – Menghini Luca Mar 30 '22 at 07:52

1 Answers1

0

You are designing this wrong. Use Cloud Run's identity-based access control instead of trying to route traffic. Google IAP (Identity Aware Proxy) will block all traffic that is not authorized.

Authenticating service-to-service

John Hanley
  • 74,467
  • 6
  • 95
  • 159
  • Sadly, I forgot to mention that while that approach was considered, it's kinda difficult to implement because we are already using the `Authorization` header to pass the auth0 between the two services (the back-end needs to know which authenticated user - in our app, not on GCP - is attempting the action linked to the endpoint) tokens: I suspect having multiple `Authorization` headers might be an issue to manage – Menghini Luca Mar 30 '22 at 07:50
  • @MenghiniLuca - You cannot use the Authorization header for your own purposes in Google Cloud if you are calling a Google service or an application in Google Cloud that enables or uses IAP (that means all compute-based services). Google Cloud will validate the Authorization header and reject traffic. That includes services that have **public** access enabled such as Cloud Functions and Cloud Run. You can use that header calling services outside Google Cloud but they might not be able to call you using that header. – John Hanley Mar 30 '22 at 08:02
  • For future readers of my comment, my statement might not be correct at some future date. Google is planning to support another HTTP header for authorization. The new header will be Proxy-Authentication. There is an issue for this item: https://issuetracker.google.com/issues/214408198 and I have tested the new feature unsuccessfully: https://stackoverflow.com/a/59297859/8016720 – John Hanley Mar 30 '22 at 08:15