Allow GCE credentials to sign blobs

[elibixby]

The IAM API which is now in Beta has a signBlob method which signs a blob on behalf of a service account for an authorized users. This should allow GCE credentials to act like fully fledged service accounts by signing blobs with this API call after acquiring an access token from the metadata server. This would only work on GCE instances that have the cloud-platform or iam scopes, but it would still be quite nice as it would allow application_default_credentials to almost always have the capacity to sign blobs.

@jonparrott

[dhermes]

Woo hoo!

[elibixby]

Started work on this master...elibixby:master
Need lots of updates to gce.AppAssertionCredentials first. Details in commit messages.

[elibixby]

@dhermes @jonparrott
So after lots of discussion with an IAM engineer, it looks like there are no plans for Service Accounts to --by default -- have permission to sign blobs on behalf of themselves.

So there are several options:

1. Drop this entirely, and say users don't need it.
2. Require users add the necessary role roles/iam.serviceAccountActor for their service account to their service account in order to sign blobs
3. Require users manually pass in an IAMSigner that is authenticated with credentials which have roles/iam.serviceAccountActor role on the gce.AppAssertionCredentials service account and pass the IAMSigner to the AppAssertionCredentials
4. Some hybrid of (2) and (3)

I think (4) is best but I'm not sure how to implement it. To see what I previously had in mind (before I was aware of this awkwardness) check out elibixby#1

[JacobHayes]

@elibixby For what it's worth, I'd much prefer this be supported (though understand time/effort is limited). If a choice between 2 vs 3, 3 (as far as I understand) gives developers a bit more testing capability while developing applications (through GoogleCredentials.get_application_default(), outside GCE), though I think a hybrid would be best as well. We use GCS to store documents (different buckets for each environment), some of which require signed urls to access. Without access to a blob signing API, we are forced to store private keys on developer boxes in order to test out that functionality in our application, which is much less than ideal (and complicates our code, requiring us to implement this ourselves).

[theacodes]

GCS on GCE/GKE is really the key use case here. I'm okay with 3/4 being the approach. Explicit is better than implicit.

[elibixby]

K, I made the implementation a little bit more flexible in the latest commit. elibixby/oauth2client@master...elibixby:iamsigner

[elibixby]

Working on a pre-pre-PR for this here #520

[elibixby]

Update: Blob signing with the metadata server is coming down the pipe from the metadata server team. An implementation that uses the metadata server will be preferable to one that uses the IAM API for a number of reasons, so I'm going to hold off implementing this until after this feature is available.

[JacobHayes]

With the understand that GCE/GKE is the key use case, does using the metadata route block the ability to use this outside GCP, like on developer boxes? Simply curious :)

[theacodes]

No, outside of GCP you'll have the private key and can sign blobs with that directly.

[JacobHayes]

Ah, yes I forget to clarify (as in #471 (comment)) that having the private key is less than favorable locally, but that's understandable. Thanks for the info

[theacodes]

Moving to googleapis/google-auth-library-python#92