Workforce Identity Federation unsupported for Cloud Run access

DevOps Google Cloud
1

Hi all!
I am trying to use Workforce Identity Federation (means human users from an external Identity Provider like Okta, Azure, and so on) to provide access to Cloud Run services.
This page - https://cloud.google.com/iam/docs/federated-identity-supported-services#cloud-run
says that it is not possible -

The IAM permission run.routes.invoke , which manages access to Cloud Run service endpoints, doesn't support Workforce Identity Federation.

Any reasoning, details, roadmaps, or any other information about the subject would be very useful, please>

2

What action are they doing that causes the run.routes.invoke ?

3

they make it seem like it would be supported for actual invocation

4

I feel it has more to do with the Cloud Run design. CR is typically used as backend for REST APIs. Might be for security reasons

5

In our case the front end is based on Cloud Run services, and we would like to (have to) use a SSO with an external Identity Provider. Thus we would prefer to use the WIF instead of an internal (inside the Cloud Run) SSO implementation. At this moment, the only option I have in mind is this one - https://cloud.google.com/iap/docs/use-workforce-identity-federation but I have not yet tried (will do shortly), so any other options or shared experience is welcome.

6

Workload Identity federation is for apps while workforce identity federation is for a workforce (human users)

7

sure. So we are after the WIF as the Workforce Identity Federation, rather than the Workload Identity Federation.

8

Yes sorry just skimmed through your message

9

There was some change with Cloud Run with IAP, it is now just a checkbox, earlier it needed a LB (it is in preview)

10

do you mean this one - https://cloud.google.com/run/docs/securing/identity-aware-proxy-cloud-run ?

11

• Identities must be from within the same organization. - will it work with an external IdP through the WIF?
• Some integrations, such as Pub/Sub, might stop working if IAP is enabled - as Cloud Run services do communicate between each other through the PubSub service - will be a serious obstacle?

12

what actually are they doing when they “access” this though? what API calls are they making??

13

I feel like the GCP way to do this would be more along the lines of IAP

14

but – you could use WIF to get a temporary credential w/ gcloud and then still use that to invoke cloud run, can’t you?

15

‘they’ - you mean human users? they work with the UI front end which is implemented as a set of cloud run services. And the access to that UI is to be protected (SSO with an external IdP)
the ‘default’ IAP implies that the IdP is Google, so a union of the IAP and WIF might be promising.

16

how about identity platform, cloud identity?

17

unfortunately no, for many reasons (including company wide). no way for identity synchronisation. Thus the Workforce Identity Federation - to try. And I am after shared knowledge, experience, links, etc.

18

IAP with WIF is the recommended path. A less ideal implementation could be service account impersonation:
• You grant your external users the ability to impersonate a Google Service Account.
• This service account has the run.routes.invoke permission.
• Your frontend code uses the impersonated service account to get tokens to call the backend.

19

Thanks!
And to grant an ability to impersonate a service account, there should be a Workforce Identity Federation in place, correct?