Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

Service to service authentication through GCLB

Hi Google Cloud Community,

The context

2 services, Service1 and Service2, each:

- deployed onto Cloud Run in multiple regions, with a specific service account and ingress configured to internal-and-load-balancing.

- exposed to the public internet though a Global HTTP(s) Load Balancer using serverless NEGs on a custom domain.

Service2:

- has a policy set on it that only allows it to be invoked by Service1's service account.

 

Service1 invokes Service2 on its custom domain, setting the Authorisation header to the value of "Bearer ${Service1-service-account-signed-JWT}". 

 

The problem

Documentation states that the target_audience claim of the JWT must be set to the value of the URL of receiving service (docs). Service2 is deployed in multiple regions, each with a different URL.

 

The question

What value should the target_audience field have so that authentication succeeds for all Service2's regions as traffic will be routed towards them by the Global HTTP(s) Load Balancer?

 

Edit: I found this guide that provides a potential solution, however, it seems to be specifically geared towards solving this problem for Pub/Sub invokers. 

Solved Solved
0 2 926
1 ACCEPTED SOLUTION

Hi, 

It appears that your use case is one of the limitations associated with Serverless NEGs as per the statement below found in the documentation here

  • "Serverless NEGs can point only to Cloud Run, App Engine, or Cloud Functions services residing in the same region where the NEG is created."

However, it also appears that the above limitation can be mitigated by configuring multi-region load balancing. The workaround should prove useful even for non Pub/Sub use cases such as yours based on this documentation.

View solution in original post

2 REPLIES 2

Hi, 

It appears that your use case is one of the limitations associated with Serverless NEGs as per the statement below found in the documentation here

  • "Serverless NEGs can point only to Cloud Run, App Engine, or Cloud Functions services residing in the same region where the NEG is created."

However, it also appears that the above limitation can be mitigated by configuring multi-region load balancing. The workaround should prove useful even for non Pub/Sub use cases such as yours based on this documentation.

Hey @Bruno ,

Using an OAuth client ID, I managed to secure a cross-regional Cloud Run deployment exposed through a load balancer. Following the docs, I:

1. Set up a landing page of OAuth.

2. Created an OAuth client ID for web applications.

3. Re-deployed the Cloud Runs so that they become aware of the newly created OAuth client ID.

4. Updated the Cloud Run invoker policy members to include specific service-accounts.

5. Requested data from the deployment authenticating with a Google ID Token whose audience was set to the OAuth client ID.

 

All of the above works! However, I'm struggling to understand how it works. I've combed the Cloud Run, IAP and Load Balancing docs, but the bigger picture still eludes me here.  It all feels a little bit like magic to me.

 

Is there some documentation that I've missed out on, that explains this? Things like:  what is the link between the OAuth client ID that I'm using as an audience and the IAM policy that I define at Cloud Run's level for the invoker role?