Support with_scopes and with_subject for GAE and GCE service accounts

[ducksauz]

Is your feature request related to a problem? Please describe.
I'm building some tooling that is intended to run as a GAE cron job that will interact with our G Suite instance via the Admin API and domain wide delegation. In order for my code to interact with the Admin API, it needs to run scoped and with_subject to properly use the delegated access to G Suite. I want to do two-legged OAuth because it's a cron job and there's no opportunity for user interaction.

I can do it like this:

credentials = service_account.Credentials.from_service_account_file(
   'service-account.json',
   scopes=['https://www.googleapis.com/auth/admin.directory.user',
         'https://www.googleapis.com/auth/admin.directory.group'],
   subject='service-account@my-gsuite-domain.com')

and this works, but I don't want to have to deploy the service account private key file with the code artifacts to make it work.

Describe the solution you'd like

I'd rather have my code be able to just pull the service account info from GAE or GCE like this:

credentials = app_engine.Credentials(
   scopes=['https://www.googleapis.com/auth/admin.directory.user',
         'https://www.googleapis.com/auth/admin.directory.group'],
   subject='service-account@my-gsuite-domain.com')

or this:

credentials = compute_engine.Credentials(
   scopes=['https://www.googleapis.com/auth/admin.directory.user',
         'https://www.googleapis.com/auth/admin.directory.group'],
   subject='service-account@my-gsuite-domain.com')

Basically, please make all the domain wide delegation goodness in google.oauth2.service_account work in google.auth.app_engine and google.auth.compute_engine .

Describe alternatives you've considered
My current workaround to this will require me to deploy the GCP service account's private key with my code artifacts to GAE, which isn't great from a security perspective.

[theacodes]

Unfortunately, the scopes for managed credentials (GCE, GAE) are fixed and we don't have the option of modifying those.

My current workaround to this will require me to deploy the GCP service account's private key with my code artifacts to GAE, which isn't great from a security perspective.

I'd suggest using KMS to manage your keys used for accessing gSuite. You can grant your GAE account access to the key in KMS. You can almost maybe use the new ImpersonatedCredentials to accomplish this.

[ducksauz]

@theacodes

Thanks for the super quick feedback, just one more (sorry, long) question and if it doesn't pan out, I'll go with the workaround.

So, maybe it's not so critical to be able to modify the scopes, as long as the scopes that I delegate to the GCP service account in G Suite work without me having to scope them in the Credentials() call. The thing that's really imperative here for me to interact with G Suite would be the ability to .with_subject() the credentials so the service account assumes the G Suite service account identity. In my working example above, without assuming the G Suite subject, all my Admin API calls 403.

So, would it possible to add .with_subject() to the GAE/GCE managed creds? 🤞

[theacodes]

Likely not. We don't have control over the access token refrsh logic there. 😔

…

On Thu, Nov 29, 2018, 1:32 PM John Duksta ***@***.***> wrote: @theacodes <https://github.com/theacodes> Thanks for the super quick feedback, just one more (sorry, long) question and if it doesn't pan out, I'll go with the workaround. So, maybe it's not so critical to be able to modify the scopes, as long as the scopes that I delegate to the GCP service account in G Suite work without me having to scope them in the Credentials() call. The thing that's really imperative here for me to interact with G Suite would be the ability to .with_subject() the credentials so the service account assumes the G Suite service account identity. In my working example above, without assuming the G Suite subject, all my Admin API calls 403. So, would it possible to add .with_subject() to the GAE/GCE managed creds? 🤞 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#310 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPUc_-F5UkhuaP0ce0qvvmcVmRjsaZqks5u0FJRgaJpZM4Y4ovA> .

[ducksauz]

Oh well. C'est la vie.
Off I go to KSM to make a keychain and key to encrypt the service account private key.
Thanks again!

[theacodes]

No worries!

…

On Thu, Nov 29, 2018, 7:33 PM John Duksta ***@***.***> wrote: Oh well. C'est la vie. Off I go to KSM to make a keychain and key to encrypt the service account private key. Thanks again! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#310 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPUc_abYczJ1iOG5bxdy2G8lXvOkZccks5u0KcWgaJpZM4Y4ovA> .

[mwallman]

You can use this method, get_delegated_credential: https://github.com/GoogleCloudPlatform/forseti-security/blob/c8d1485e5c88673d8c6190ba0e9a7c22013db385/google/cloud/forseti/common/gcp_api/api_helpers.py#L29-L66

[ducksauz]

You can use this method, get_delegated_credential: https://github.com/GoogleCloudPlatform/forseti-security/blob/c8d1485e5c88673d8c6190ba0e9a7c22013db385/google/cloud/forseti/common/gcp_api/api_helpers.py#L29-L66

Awesome! Thanks for the pointer. I'll try it out.

[mwallman]

https://github.com/GoogleCloudPlatform/professional-services/tree/master/examples/gce-to-adminsdk

[xanjay]

I'm experiencing below issue. I've already added roles/iam.serviceAccountTokenCreator.
Does anyone have an idea?
"""
ERROR:503 Getting metadata from plugin failed with error: Error calling the IAM signBytes API: b'{\n "error": {\n "code": 403,\n "message": "The caller does not have permission",\n "status": "PERMISSION_DENIED"\n }\n}
"""