Expected Behavior
The google_secretmanager provider should authenticate using Application Default Credentials (ADC), including the user credentials ("type": "authorized_user") written by gcloud auth application-default login — the common flow for local development without a service-account key.
Current Behavior
When ADC resolves to user credentials, authentication fails:
Error: Bad service account key: missing field `private_key`
The provider authenticates via yup-oauth2's ApplicationDefaultCredentialsAuthenticator, which only accepts service-account keys or the GCE metadata server.
Possible Solution
In teller-providers/src/providers/google_secretmanager.rs, resolve_auth() tries ADC as a service account first; when GOOGLE_APPLICATION_CREDENTIALS points at an authorized_user file the SA builder errors with missing field 'private_key', and that error propagates before the authorized_user fallback can run.
Proposed fix: migrate the provider to Google's official SDK crates google-cloud-secretmanager-v1 + google-cloud-auth, whose ADC resolver handles authorized_user, service-account, impersonated / external accounts and the metadata server out of the box. This drops the yup-oauth2 / google-secretmanager1 stack and the manual resolve_auth, and is contained to this provider. I have a working branch (compiles; live-tested against Secret Manager with gcloud user ADC) and can open a PR.
Steps to Reproduce
gcloud auth application-default login (writes ~/.config/gcloud/application_default_credentials.json, "type": "authorized_user").
export GOOGLE_APPLICATION_CREDENTIALS=$HOME/.config/gcloud/application_default_credentials.json
- Create
.teller.yml:
providers:
gsm:
kind: google_secretmanager
maps:
- id: t
path: projects/YOUR_PROJECT
keys:
SOME_EXISTING_SECRET: OUT_VAR
teller show
Context
Blocks using teller for local development against Google Secret Manager with a developer's own gcloud login (the common no-service-account-key flow); only static service-account keys work today.
Specifications
- Version:
teller 2.0.7
- Platform: Linux (x86_64) — auth path is platform-independent
Expected Behavior
The
google_secretmanagerprovider should authenticate using Application Default Credentials (ADC), including the user credentials ("type": "authorized_user") written bygcloud auth application-default login— the common flow for local development without a service-account key.Current Behavior
When ADC resolves to user credentials, authentication fails:
The provider authenticates via
yup-oauth2'sApplicationDefaultCredentialsAuthenticator, which only accepts service-account keys or the GCE metadata server.Possible Solution
In
teller-providers/src/providers/google_secretmanager.rs,resolve_auth()tries ADC as a service account first; whenGOOGLE_APPLICATION_CREDENTIALSpoints at anauthorized_userfile the SA builder errors withmissing field 'private_key', and that error propagates before theauthorized_userfallback can run.Proposed fix: migrate the provider to Google's official SDK crates
google-cloud-secretmanager-v1+google-cloud-auth, whose ADC resolver handlesauthorized_user, service-account, impersonated / external accounts and the metadata server out of the box. This drops theyup-oauth2/google-secretmanager1stack and the manualresolve_auth, and is contained to this provider. I have a working branch (compiles; live-tested against Secret Manager with gcloud user ADC) and can open a PR.Steps to Reproduce
gcloud auth application-default login(writes~/.config/gcloud/application_default_credentials.json,"type": "authorized_user").export GOOGLE_APPLICATION_CREDENTIALS=$HOME/.config/gcloud/application_default_credentials.json.teller.yml:teller showContext
Blocks using teller for local development against Google Secret Manager with a developer's own
gcloudlogin (the common no-service-account-key flow); only static service-account keys work today.Specifications
teller 2.0.7