Google Drive access control

Help and Support
1

What is the problem you are having with rclone?

I'm trying to back up multiple remote hosts to a business Google Drive. Following "least-privilege", I want to apply access control such that each host is isolated from each other as well as the end-user Google account's files.

User
| Host A
| Host B
| Host C

How can I configure rclone's access tokens to achieve this?

Service accounts get me most of the way there, but Google Drive's storage quota applies to the file owner, so is limited to its own 15GB, rather than the user's multiple TBs. --drive-impersonate solves this, but then breaks isolation.

Run the command 'rclone version' and share the full output of the command.

rclone 1.68.0

  • os/version: nixos 24.11 (64 bit)
  • os/kernel: 6.11.0 (x86_64)
  • os/type: linux
  • os/arch: amd64
  • go/version: go1.22.7
  • go/linking: dynamic
  • go/tags: cmount

Which cloud storage system are you using? (eg Google Drive)

Google Drive

The command you were trying to run (eg rclone copy /tmp remote:tmp)

Paste command here

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

[google_drive]
type = drive
client_id = XXX
client_secret = XXX
scope = drive.file
service_account_credentials = XXX
2

welcome to the forum,

sorry, no idea about that. maybe if each user had their own drive.appfolder

i know with S3 remotes and using polices, it would be trivial.
i would think|assume that gdrive, when using service accounts, has some sort of basic policies for users and folders?

just brainstorming, wanted to point out.
if each rclone user had their own crypt remote, each with their own crypt passwords,
then one user could not decrypt the other user files.

3

My current set up is a folder per host (with root_folder_id), each shared with their individual service account. This worked well until I discovered they don't inherit the user's storage quota.

4

It's extra upfront set up work, but one solution is creating a app/Google Cloud project/OAuth consent screen per host and using the drive.file (or drive.appfolder) token scope.

Note, if you're using service accounts, client_id/client_secret is ignored in favour of service_account_credentials and so you'll also still need a separate Google Cloud project per host.

If using impersonation, scope is ignored in favour of the scope(s) specified in Domain-wide delegation.

5

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.