Keep GCP ADC identity stable across provider refreshes
- Lenguaje dominante
- Rust
- Estrellas
- 54.2k
- Forks
- 6.2k
- Merge medio
- 3 d 4 h
- PR fusionados (30 d)
- 240
Descripción
**What problem would this solve?**
Google Application Default Credentials are discovered in an ordered chain: an explicit file, the well-known local gcloud file, then metadata credentials. A live Goose provider can rerun that discovery after an authentication failure. If the originally selected well-known file disappears, refresh may silently switch the provider from the user's account to an ambient VM or workload service account and replay a request under a different principal.
It is unclear whether a provider lifetime should preserve the initially selected credential source and identity, or whether every refresh is expected to perform fresh ADC discovery.
**What would a good outcome look like?**
Goose documents and enforces an explicit credential-continuity contract. Authentication refresh cannot silently increase or change the principal used by an existing provider unless that behavior is intentionally supported and visible to the operator. Normal refreshes and replacement of the same gcloud credential file continue to work.
**Possible approaches**
- Pin the selected ADC source class and path for the provider lifetime; fail closed if that source disappears.
- Pin a stable principal/account identity and allow source replacement only when the identity is unchanged.
- Treat any source or principal change as provider reconfiguration requiring explicit operator action.
- If fresh ADC rediscovery is intentional, surface the resulting identity transition and define which retries may replay requests under it.
- Cover explicit credential files, the well-known gcloud file, metadata credentials, 401/403 retries, and token-refresh failures.
**Additional context**
The key decision is whether a provider that initially selected file-backed ADC may ever fall through to metadata credentials during refresh without explicit operator action. Implementation should wait until the issue reaches **Ready** on the Goose Issues board.
- [x] I have verified this does not duplicate an existing feature request
Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).
Guía de contribución
Línea de trabajo
El issue trata sobre el manejo de Google Application Default Credentials (ADC) en el Goose provider. Busca la lógica de autenticación y renovación del provider, probablemente en un módulo relacionado con GCP o credentials. Comprende la cadena de descubrimiento de ADC (archivo explícito, archivo de gcloud, metadatos). El objetivo es diseñar un contrato para la continuidad de las credentials que evite cambios silenciosos del principal. Empieza revisando el código de autenticación existente y las pruebas de renovaciones de ADC.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- gcp, google-cloud, rust
- Área
- authentication, backend-api-design, cloud
- Tipo de issue
- Nueva funcionalidad
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Estado de actividad
- Activo
- Claridad
- Bastante claro
- Aptitud para principiantes
- 35/100