Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does drive support service accounts, so G Suite users can automate initialisation without user prompts? #879

Closed
cajacko opened this issue Feb 11, 2017 · 9 comments

Comments

@cajacko
Copy link

@cajacko cajacko commented Feb 11, 2017

Does this utility support using a separate service account credentials.json file? And how would you go about setting this up?

This would be great as I could automate the whole initialisation process without user prompts. Which would work well in my continuous deployment setup.

I'm imagining something where you could specify a separate credentials file during initialisation:

drive init --credentials credentials.json
@odeke-em

This comment has been minimized.

Copy link
Owner

@odeke-em odeke-em commented Feb 12, 2017

Hello there @cajacko, thank you for the question and welcome to drive!

Unfortunately we don't support service accounts since there hasn't been any demand for them.
We currently only support OAuth2.0 credentials since they are revokable.

Therefore I'll take this as the first request for support for Google Service Accounts. I have added
support for Google Service Accounts for proprietary code for Google related services but not here.

Instead of reading credentials from the environment .gd/credentials.json, we could follow the style
of resolution for Google Service account credentials. We can then change up the remote context resolver in here

drive/src/remote.go

Lines 96 to 105 in 5278f2b

func NewRemoteContext(context *config.Context) *Remote {
client := newOAuthClient(context)
service, _ := drive.New(client)
progressChan := make(chan int)
return &Remote{
progressChan: progressChan,
service: service,
client: client,
}
}
to get OAuth2.0 credentials directly from the GSA credentials as is done here https://github.com/golang/oauth2/blob/3c3a985cb79f52a3190fbc056984415ca6763d01/google/example_test.go#L58-L79 and just swap out how we initialize the service.

I'll mark this as a feature-request and if anyone would like to work on it, please feel free or I'll jump in, in about a week when I get a break from school.

@odeke-em odeke-em added this to the v0.4.0 milestone Feb 12, 2017
odeke-em added a commit that referenced this issue Feb 12, 2017
Fixes #879.

Allows using Google Service Accounts.
However, it is a little awkward to use them because
we still need an init/mount point on disk.
WIP that I'll get to perhaps when the school break
is on.
@odeke-em

This comment has been minimized.

Copy link
Owner

@odeke-em odeke-em commented Feb 12, 2017

@cajacko I've started the work here, initialization for the remote should be complete, what's left is figuring out the initialization process 8eb5d20
but am thinking using GSA accounts with init is a little awkward since the recommended
method of using them is by resolving them from the environment variable but no biggie
we can read from a file itself using https://github.com/golang/oauth2/blob/master/google/jwt.go#L26.

WIP that I'll complete next week when free.

@cajacko

This comment has been minimized.

Copy link
Author

@cajacko cajacko commented Feb 12, 2017

@odeke-em Awesome, thanks for the quick response and progress on this!

odeke-em added a commit that referenced this issue Feb 19, 2017
Fixes #879.

Allows using Google Service Accounts.

To do so, initialize it with GSA credentials in JSON form:
```shell
$ drive init -service-account-file ~/Desktop/gsaFile.json
```

Please make sure that you've enabled the Drive API
and if you've enabled the API recently, wait a couple of minutes
for the action to propagate through Google's systems, then retry.
@odeke-em

This comment has been minimized.

Copy link
Owner

@odeke-em odeke-em commented Feb 19, 2017

@cajacko thanks for the wait, I've added support for Google Service Accounts with PR #882, please get the latest from master by

$ go get -u -v github.com/odeke-em/drive/drive-gen && drive-gen

Please let me know if anything isn't right or if there are any problems.

@cajacko

This comment has been minimized.

Copy link
Author

@cajacko cajacko commented Feb 21, 2017

Hey, Thanks so much for working on this. The connection is working great and I am able to pull/push/list etc.

However I'm not sure what account I am looking at. As there isn't anywhere to specify the user you want to make drive calls on behalf of. I'm not sure whose drive account it is, all that is inside it is a "Getting Started" document.

On the Google docs (https://developers.google.com/identity/protocols/OAuth2ServiceAccount) it mentions the following:


Additional claims

In some enterprise cases, an application can request permission to act on behalf of a particular user in an organization. Permission to perform this type of impersonation must be granted before an application can impersonate a user, and is usually handled by a domain administrator. For more information on domain administration, see Managing API client access.

To obtain an access token that grants an application delegated access to a resource, include the email address of the user in the JWT claim set as the value of the sub field.

Name Description
sub The email address of the user for which the application is requesting delegated access. If an application does not have permission to impersonate a user, the response to an access token request that includes the sub field will be an error.

An example of a JWT claim set that includes the sub field is shown below:

{
  "iss":"761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "sub":"some.user@example.com",
  "scope":"https://www.googleapis.com/auth/prediction",
  "aud":"https://www.googleapis.com/oauth2/v4/token",
  "exp":1328554385,
  "iat":1328550785
}

Is this something that would need to be implemented to access a specific drive account, or am I missing something in the Google Drive config side of things?

Thanks

@odeke-em

This comment has been minimized.

Copy link
Owner

@odeke-em odeke-em commented Feb 21, 2017

Hello @cajacko, thanks for the question. Unfortunately I don't know how to request for exact user access for a service account, because I use service accounts only for apps and organization. For example you have an app that receives selfies by upload, so you create a console.developers.google.com project and enable Google APIs access to it such as Google Drive.

So in that citation, they say set "sub" as the email of the user you'd like to use it for. Please set "sub" as the email of the user just like you would when doing the OAuth2.0 exchange in the credentials, and let's see what changes. Initializing with the JWT config ie drive init -service-account-file ~/Desktop/gsaFile.json -- assumes that the credentials have already been exported correctly, so you'll need to add that field yourself.

@cajacko

This comment has been minimized.

Copy link
Author

@cajacko cajacko commented Feb 22, 2017

Hi, I added the sub property and desired email into the credentials file to no effect. Although I have been able to access a users folders by sharing them with the service account email address. So now I am able to pull a shared folder by it's ID, which is great. Although I am unable to push to a shared folder, as there does not seem to be an accompanying push by id option. Is there any support for pushing/pulling from shared folders that I am missing?

Here is a bit of context to help understand what I'm trying to do:

An organisation that uses G Suite, has unlimited drive capacity for it's users and wants to use this storage to backup data from various servers. This servers may be setup entirely with continuous deployment so the setup needs to be autonomous.

One of the users creates a backups folder that is shared throughout the organisation. This is the folder that they want the server to be backed up to.

At the moment this drive utility can be setup automatically, can pull the latest backups from the shared folder (by ID) and the last piece of the puzzle is just to be able to push to it.

This shared folder must be shared from a user account, rather than being owned by the service account, as the service account can only have the default storage quota and the organisation is already paying for unlimited storage for it's users.

Thanks

@odeke-em

This comment has been minimized.

Copy link
Owner

@odeke-em odeke-em commented Feb 23, 2017

Hmm, @cajacko unfortunately that's out of my knowledge scope, let me ping our Googler coauthor @rakyll for help.
@rakyll do you know to use GSA credentials on behalf of a user? Thanks.

@muratgozel

This comment has been minimized.

Copy link

@muratgozel muratgozel commented Nov 18, 2018

I had this issue recently and realized that drive creates credentials.json (~/gdrive/.gd/credentials.json) file after initiation. You will see that there is a Subject field in this file which is set to an empty string. So I tried my chance and set it to an email address which is delegated under the service account i've specified. And it worked! 🕺

I would like to make a pr related to this but i don't even know the go lang.

You can automate this job with the following:

sed -i -e 's|"Subject":""|"Subject":"'"$GOOGLE_DRIVE_BACKUP_USER"'"|g' ~/gdrive/.gd/credentials.json
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.