Calling vertexai endpoint via apigeex using GoogleAccessToken using impersonating other target SA

Google Cloud Apigee
1

Hi @kurtkanaskie @dchiesa1

We are trying to call private IP PSC based vertexai endpoint in other GCP project from apigeex . apigeex SA has got access to impersonate target GCP project SA & target GCP project SA has the access to generate access token.

How does the HTTPTargetConnection with GoogleAccessToken config looks like when apigeex SA has to impersonate target GCP project SA for generating the GoogleAccessToken to call the VertexAPI endpoint?

<Authentication>

https://www.googleapis.com/auth/cloud-platform

xxxxx-sa@xxxxxx.iam.gserviceaccount.com

https://xxxxx/v1/projects/xxxxx/locations/xxxxxx/endpoints/xxxxx:predict

2

Hi @raghunathapalle

In my examples I merely added the SA from the source project to the target project in IAM with the appropriate Roles (e.g. Cloud Run Invoker). cloud-run-oidc@source-project.iam.gserviceaccount.com

The target connection

    <Authentication>
      <GoogleIDToken>
        <Audience>https://hello-edge-oidc-demo-us-east1-259582898922.us-east1.run.app</Audience>
        <IncludeEmail>true</IncludeEmail>
      </GoogleIDToken>
    </Authentication>

And then deploy the proxy using that SA.

cloud-run-oidc@source-project.iam.gserviceaccount.com

2 Likes
3

How does the HTTPTargetConnection with GoogleAccessToken config looks like when apigeex SA has to impersonate target GCP project SA for generating the GoogleAccessToken to call the VertexAPI endpoint?

I understand what you’re asking but I would like to adjust it a little bit. I don’t think of it as “impersonation” but rather… the APigee proxy adopts that identity. It IS that identity.

This may be a minor thing, and I’m sure you understand the nuance, but my point might be helpful to others in understanding. I use “impersonate” when the thing, the primary subject, is taking the identity of another thing, let’s call it the secondary subject. So for example if I am using curl from my terminal. My normal identity is something I obtain with gcloud auth login and gcloud auth print-access-token. In other words I have a primary identity. Then if I want to use some other identity, we could say I will impersonate a service account, for example.

With gcloud I would use this:

gcloud auth print-access-token --impersonate-service-account ${SA}

…where SA is an environment variable holding the full email address of a service account.

I have my primary identity and then with that command I would get a token impersonating a secondary identity, that of the service account.

…Now…When you deploy an Apigee proxy with a service account, it is not impersonating. The service account is the primary identity used by the API Proxy. So in my mind it is not correct to ask
“when apigeex SA has to impersonate target GCP project SA”. Instead we are only obtaining an access token for the primary identity of the proxy.

This might be an irrelevant difference for most people, but I thought it might be helpful to point out.

BTW this screencast covers different ways for Apigee proxies to use identity when calling upstream systems. I used Cloud Run in the screencast, but similar patterns work with Vertex AI, BigQuery and so on. But be aware, Cloud Run requires ID Tokens.; those other systems will require ACCESS tokens.

1 Like