feat(impersonated): add impersonated credentials auth

[salrashid123]

Fixes #535

Adds ImpersonatedCredentials. This credential type basically takes one source credential and exchanges it for another, different service account.

for reference, it exists currently in:

• google-auth-python: google.auth.impersonated_credentials.html

• google-auth-java: ImpersonatedCredentials.java

---

I do NOT have testcases that cover this (any pointers or sample on how to do the exchange (i.,e two round trips for the token would be appreciated)

---

• Usage:

const {Logging} = require('@google-cloud/logging');
const { GoogleAuth, JWT, Impersonated, ImpersonatedOptions  } = require('google-auth-library');
const { Storage } = require('@google-cloud/storage');
const {Logging} = require('@google-cloud/logging');

var svcAccountFile = 'svc_account.json';
var project_id = 'yourprojectID';


const keys = require(svcAccountFile);

// create a sourceCredential
let saclient = new JWT(
  keys.client_email,
  null,
  keys.private_key,
  ['https://www.googleapis.com/auth/cloud-platform', 'https://www.googleapis.com/auth/iam'],
);


// Use that to impersonate the targetPrincipal
let targetClient = new Impersonated({
  sourceClient: saclient,
  targetPrincipal: "target@anotherproject.iam.gserviceaccount.com",
  lifetime: 30,
  delegates: [],
  targetScopes: ["https://www.googleapis.com/auth/cloud-platform"]
});

// At this point you can use the client as any other:

// 1. Acquire Headers
const authHeaders = await targetClient.getRequestHeaders();
console.log(authHeaders);

// 2. Use client in authorized session 
targetClient.getAccessToken().then(res => {
  let url = 'https://www.googleapis.com/storage/v1/b?project=' + project_id
  targetClient.requestAsync({ url }).then(resp => {
    console.log(resp.data.items[0]);
  }).catch(function (error) {
    console.error('Unable to list buckets: ' + error);
  });
});

// 3. Use client with GCP Service 
const { Logging } = require('@google-cloud/logging');

const log = logging.log('mylog');
const text = 'Hello, world!';
const metadata = {
  resource: {type: 'global'},
};
const entry = log.entry(metadata, text);
await log.write(entry);
console.log(`Logged: ${text}`);

[bcoe]

@salrashid123 @JustinBeckwith I will make an effort to provide code review on this tomorrow 👍

[bcoe]

this is looking really solid, mainly a few initial questions.

[bcoe]

If I need to hold the actual credentials to generate the impersonated client, how does this provide improved security. I think I just don't fully understand the threat model this protects me from (not be a security person).

[salrashid123]

You'll always need some credentials to bootstrap with but this capability basically allows you to impersonate another credential

you can do something like this: You own serivceAccoutnA, I own serviceAccountB and I give B permissions on GCS BucketG that i own; A does not have permission on G.

I can create an IAM condition that says "only allow A access to impersonate B between 1am and 2am". So what serviceAccountA has is temp access to bucketG.
You can basically continue this chain of delegation. The full flow is described here

• https://cloud.google.com/iam/docs/creating-short-lived-service-account-credentials

[bcoe]

it might be worth pulling this endpoint into a variable, and perhaps even making it configurable with ImpersonatedOptions.

[salrashid123]

ok added in an option

[bcoe]

is the idea that it will immediately refresh the token on the first request, because the impersonated account hasn't yet been created?

[salrashid123]

yeah, i derived that idea from how google-auth-python does its refresh of creds. Should i init creds on creation (i was just blindly copying the existing compute implementation here)

[bcoe]

I'm going to switch some of the promise logic to use await, but otherwise this is honestly looking very solid; I believe we'll want to add documentation, which I will create a tracking ticket for.

[bcoe]

this is blocked while we have a few internal discussions about how to make auth more extensible.

[bcoe]

@bshaffer is this functionality partially addressed by your work around id tokens.

[salrashid123]

hi-
They're two different things though: @bshaffer 's work is about generating and using a serviceAccount's OpenIDConnect token (OIDC)...the PR here is just about impersonating a service account (i.,e you impersonate serviceAcountA and get its access_token (not OIDC token)

[bshaffer]

To echo @salrashid123, as far as I know this work is not related to the ID token work I've done.

[robhogan]

@bcoe is there anything we can do to help move this PR along? I'm not sure what's still outstanding.

(IIUC this functionality would be very useful in local development, to allow an individual developer's local credentials to impersonate a service account - some GCP APIs only support access by service accounts - without the developer needing a private SA key file on their machine)

[bcoe]

@rh389 I apologize for the slow reply, I would love to get this work moving again. I'm going to bring it up with a few folks internally and see what we can make happen.

[Mistic92]

Hi, we'd use this feature too :) For example for vision api we need service account from exact project as adding from other one is not working. Fortunatelly impersonation is working and we wanted to use it but without this feature we are blocked

[bcoe]

@salrashid123 not quite sure what happened, had a merge conflict updating your PR, changes incoming.