impersonate service account and deploy to apigee proxy to invoke 3rd party system from apigee

[aramkrishna6]

Hi,

If we have a service account and 3rd party target application to apigee only accepts service account impersonate as indicated in

Create short-lived credentials for a service account  |  IAM Documentation  |  Google Cloud 

Do we have any sample apigee proxy to refer which will list the service account deployment to apigee and invoke any 3rd party application. We have service account with required IAM permission

@dino @anilsagar 

[dchiesa1 · Accepted solution]

I'm not quite clear on the data path. I think

• you have an Apigee proxy
• the target of that proxy is a 3rd-party system
• the 3rd-party system accepts ... some kind of bearer token for authentication. (Access token? ID token? which?)
• The third party system expects the token to identify a GCP Service account.

Is that about right?

If so, then yes, You can deploy an API proxy with a service account, so that Apigee uses that service account identity for outbound calls made by that proxy. Apigee will inject an outbound Authorization header with either an ID token or an Access token, depending on the configuration you use. Outbound calls include the Target, and any ServiceCallout. Some notes on that:

1. If YOU are the one deploying the proxy, either via the UI, or via the Apigee API, or via a tool that wraps the API like apigeecli, then you need to have permission to specify that service account when you deploy the proxy . To get that set up, you can do this:

   gcloud iam service-accounts add-iam-policy-binding $EMAIL_OF_SA_FOR_PROXY \
       --project $SA_PROJECT \
       --member=user:youremail@yourorganization.com  \
       --role=roles/iam.serviceAccountUser 
   

   On the other hand, If you use an automated CI tool to deploy the proxies (like cloud build or something similar), then you need to grant the same role to the service account that your tool runs as. In this case there would be two service accounts, one that provides the identity of the CI tool, and a second one that provides the identity of the api proxy. The first needs permission to actAs the second:

   gcloud iam service-accounts add-iam-policy-binding $EMAIL_OF_SA_FOR_API_PROXY \
       --project $SA_PROJECT \
       --member=serviceAccount:deployer-sa@project-name.iam.gserviceaccount.com  \
       --role=roles/iam.serviceAccountUser 
   

2. The required configuration is to use the Authentication element in the HTTPTargetConnection . I just answered a similar question a week ago on this, describing the different options for configuration of this element. Find that post here. If you want to read the reference documentation for that Authentication element , look here.