Apigee X in shared VPC environment but with Cross-Project Service Account Usage disabled

[vince2025]

My company has a shared VPC setup and, and we will setup a Apigee X on a new service project to serve traffic from client to our internal workload on GCP.  This Apigee X will route traffic to backend service inside other service projects. ( which are cloud run functions and they also sit behind their own load balancer) . 

Since there is an organization policy "Disable Cross-Project Service Account Usage" enabled, using service account with role binding is not feasible to authenticat with.  I heard using the workload identity federation but since we are internal system interaction, we do not use external provider or should have access to external identity provider. we hope to manage those via GCP IAM. 

[hartmann · Accepted solution]

Hello,

Have you thought of using networking constructs/Private Service Connect to authenticate to this service? You could do something along the lines of Traffic -> Apigee -> ILB -> Serverless NEG -> Cloud Run function, and present that Cloud Run service as a Service Attachment to Apigee. Apigee could then in theory consume that service via Endpoint Attachment as noted here: https://cloud.google.com/apigee/docs/api-platform/architecture/southbound-networking-patterns-endpoi...

Let me know your thoughts, thanks!

[hartmann · Accepted solution]

Hello,

Have you thought of using networking constructs/Private Service Connect to authenticate to this service? You could do something along the lines of Traffic -> Apigee -> ILB -> Serverless NEG -> Cloud Run function, and present that Cloud Run service as a Service Attachment to Apigee. Apigee could then in theory consume that service via Endpoint Attachment as noted here: https://cloud.google.com/apigee/docs/api-platform/architecture/southbound-networking-patterns-endpoi...

Let me know your thoughts, thanks!

[gonzalezruben · Accepted solution]

The idea to use WIF to circumvent cross-project SA usage is worth exploring. You don't have to have an external OIDC provider. Instead, you can use the GenerateJWT policy in Apigee to mint a new token that will can be trusted by a workload identity pool in the service project.

The identity pool in the service project can be configured to verify Apigee tokens without having to rely on a JWK endpoint, and it should also be configured to map an Apigee subject claim. If you've set a security perimeter with VPC-SC, then Apigee can also exchange the JWT token for a temporary token (sts service) that can be used to impersonate a privileged service account.

[AlexET]

Hello! 🙂 We noticed your recent question in the forum and wanted to ensure you found the information you were looking for. 

If a solution was helpful, marking it as accepted is a great way to assist other community members.

You can find further resources and articles on related topics here: https://www.googlecloudcommunity.com/gc/Cloud-Product-Articles/tkb-p/cloud-articles/label-name/apige... 

We also host weekly office hours every Thursday at 4:00 PM CET, covering API management &  integrations. Feel free to join us here: https://rsvp.withgoogle.com/events/apigee-emea-office-hours-2024/home.

We hope this helps!