Feature request: add --impersonate-service-account flag for keyless per-mount identity

[tigeryst]

Is your feature request related to a problem? Please describe.

When mounting multiple GCS buckets with different service account identities (e.g. for per-bucket access isolation), gcsfuse currently requires persistent SA key files via --key-file. There's no way to specify service account impersonation at mount time using short-lived, automatically-refreshed credentials.

The desired fstab configuration would look like:

bucket-a /mnt/bucket-a gcsfuse rw,_netdev,impersonate_service_account=sa-a@project.iam.gserviceaccount.com
bucket-b /mnt/bucket-b gcsfuse rw,_netdev,impersonate_service_account=sa-b@project.iam.gserviceaccount.com

This is not possible today without key files.

Describe the solution you'd like

A new --impersonate-service-account flag (and corresponding impersonate_service_account fstab option) that:

1. Takes a service account email as its value
2. Uses the ambient credentials (VM default SA, ADC, etc.) to obtain short-lived tokens for the target SA via the IAM Credentials API
3. Auto-refreshes tokens as they expire — no manual token management, no mount interruption

The Go ecosystem already supports this pattern cleanly. The google.golang.org/api/impersonate package provides a TokenSource that handles the full credential chain and auto-refresh transparently. Since gcsfuse is written in Go and already uses the Cloud Storage Go client, this would wire in naturally as an additional option.WithTokenSource(...) path in the credential setup logic.

The required IAM permission is roles/iam.serviceAccountTokenCreator on the target SA, granted to the caller's identity — a standard, auditable IAM binding with no persistent secrets.

Describe alternatives you've considered

• --key-file per mount: Works, but persistent SA keys are a security risk and an operational burden to rotate.
• Pre-generating ADC impersonation files: Possible since Error when using impersonated service account #647 was resolved in v0.40, but the impersonated_service_account credential type in the ADC file still carries an expiry — making long-lived mounts fragile without an external token-refresh daemon.
• Wrapper scripts with gcloud auth print-access-token --impersonate-service-account: Access tokens expire (1 hour default) and break the mount; not suitable for persistent mounts.
• --token-url: Could be used with a local token server, but requires a separate process per SA and adds significant complexity.

Additional context

The gcloud CLI has supported --impersonate-service-account since 2020, and other Google Cloud OSS tools have since added the flag for the same reasons (e.g. cloud-sql-proxy #417). This would bring gcsfuse to parity for teams that follow a keyless security posture.

The use case is particularly common on GCE VMs where the VM's attached SA has Token Creator on multiple target SAs, and each mount point should operate with least-privilege access to its respective bucket.

[gotti19868686-cloud]

[gotti19868686-cloud]

Rer