IssueTracker

Hi Everyone,

IAP for Cloud Run is a preview feature which is subject to breakage at any time and is not suited for production. The product team is aware of the breakage as it pertains to modes of GCLB that leverage Envoy proxy and a fix is in progress.

As for workarounds: customers can switch Global external HTTP(S) load balancer (classic) which during internal testing has proven to not be broken.

A couple things to keep in mind when using the above workaround. IAM members responsible for the request must have the Cloud Run Invoker & IAP-secured Web App User roles. Note that enabling of IAP and providing new roles to IAM members may take a few minutes to propagate, so ensure you wait the needed time before testing. Additionally, when making a request via a service account please make sure the audience is set to the Client ID value associated with your IAP (of the form PROJECT_NUMBER-RANDOMHASH.apps.googleusercontent.com). This client can be found by going to the IAP Cloud Console page clicking on the ..., then selecting "Go to OAuth configuration".

For those with an NGINX proxy issue, a workaround is to remove the JWT token header that causes to Block requests to Cloud RUN

location /api/ {
   proxy_set_header        X-Goog-Iap-Jwt-Assertion "";

   # proxy to the public cloud run instance
   proxy_pass https://myCloudRun-123456basd-ew.a.run.app/;
}

Hope that helps someone else

I am glad ma...@ml6.eu :)

the IAP headers are important if you need to authenticate them in the backend https://cloud.google.com/iap/docs/signed-headers-howto#:~:text=The%20JWT%20is%20in%20the,in%20case%20someone%20bypasses%20IAP.

it looks like the problem is that Cloud RUN internal load balancer tries to do "some validations" with that JWT token by default and it fails if something is proxying the original IAP request. If the token is missing then it doesn't validate and, therefore, block

An update: IAP for Cloud Run on GCLB Envoy and GCLB classic are now working.

The only remaining issue is that forwarding requests without stripping the x-goog-iap-jwt-assertion header will lead to a 403. Until a proper fix is released, we recommend customers to strip this header before forwarding requests.

Sorry for the inconvenience (IAP for Cloud Run is a Preview feature)

For those with an NGINX proxy issue, a workaround is to remove the JWT token header that causes to Block requests to Cloud RUN

Dropping the header with proxy_set_header fixed things for me #12, thank you! Good luck luck team!

Traffic with the x-goog-iap-jwt-assertion header will no longer lead to a 403. We expect customers who are forwarding the header to stop receiving 403s.

Thanks all for your patience as we worked to resolve this issue.

#22 Trying that and forwarding all headers, I can see that the cloud run now doesn't receive the x-goog-iap-jwt-assertion header. Is it being removed automatically now? If so, is there a way to validate the secure the IAP Backend as described here ?

Thanks

Are you using an Envoy based GCLB? If so, the x-goog-iap-jwt-assertion header being stripped has been and continues to be a known issue documented in https://cloud.google.com/iap/docs/enabling-cloud-run#known_limitations

we are using a classic load balancer sending IAP request to Cloud. The scenario is the following:

• we used to see the token forwarded by nginx to Cloud Run as header in the Cloud Run request before the issue and validated as documented here
• we modify our proxy to strip the header because of the issue
• after the issue has been fixed we removed the stripping of the header as it was originally
• x-goog-iap-jwt-assertion Header still not coming to the final cloud run

hope that helps Thanks

I have set up a test project that routes a request through a classic GCLB with IAP enabled and a Cloud Run backend and I was able to see the x-goog-iap-jwt-assertion reaching my Cloud Run application.

I suggest looking into your application to see if there may be somewhere else you are stripping this header. If you still have trouble I encourage you to open a GCP support case via the Cloud Console.