Support workload identity federation for plugin credentials

Abierto
  • ¿Algo no está bien?
#3,122 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
aws, azure, gcp, typescript
Área
authentication, backend-api-design, security

Línea de trabajo

Start with packages/junior-plugin-api/src/manifest.ts, chat/pi/gateway-auth.ts, and the existing grantForEgress/issueCredential lease path referenced in the issue. Read how plugin credentials are declared and how host egress caches leases. The issue is done when plugins can declare a host-minted, refreshed federated credential with a configurable header and the stated security controls, with GCP as the first exchange provider.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Plugins cannot authenticate to services that need short-lived credentials issued to a workload, such as apps behind Google Cloud IAP. Vercel issues per-deployment OIDC tokens that GCP (and AWS/Azure) can trust through workload identity federation, so no long-lived cloud key is needed. Junior has no shared primitive for this.

Current behavior

  • Manifest credentials support only oauth-bearer (packages/junior-plugin-api/src/manifest.ts): a token from a host env var or per-user OAuth, injected for the listed domains. api-headers are static values with env refs.
  • Packaged plugins can issue short-lived header leases with grantForEgress + issueCredential (the GitHub plugin does this). Host egress caches a lease until its expiresAt.
  • Core uses Vercel OIDC only for AI Gateway auth (chat/pi/gateway-auth.ts) and for verifying sandbox egress requests. Plugins have no way to get the deployment's OIDC token, and there is no shared GCP token exchange.

Gap

  • IAP needs a Google-signed credential that is valid for at most 1h. A static env token cannot work. The only option today is a JSON service account key in env, which is the long-lived secret that federation removes.
  • Every plugin that needs this must rebuild Vercel OIDC → Google STS → IAM Credentials, with its own caching and security checks.
  • Some upstreams use Authorization for their own auth (Redash: Authorization: Key …). The proxy credential then has to go in Proxy-Authorization, which IAP supports. Manifest credentials cannot choose the header today.

Capabilities identified in design discussion

  • Host workload identity exchange: a plugin credential trades the deployment's Vercel OIDC token for a short-lived cloud credential. GCP first: STS exchange, then IAM Credentials (signJwt, generateIdToken, generateAccessToken) on one named service account.
  • Declared in plugin.yaml: a plugin such as Redash should need no code. Inputs: domains, workload identity provider audience, service account, token kind and audience (for example an IAP service-account JWT with aud: https://<host>/*), and target header.
  • Configurable target header, including Proxy-Authorization, used alongside static api-headers.
  • Lease caching and refresh before expiry, through the existing egress lease path.
  • Security invariants:
    • Mint only on the host. Never expose the token to the sandbox or the model.
    • No long-lived cloud keys.
    • Document the provider attribute condition that limits trust to production deployments (sub = owner:<team>:project:<project>:environment:production), because team members can pull development OIDC tokens locally.
    • Emit telemetry for each mint.

Motivating case

An internal Redash instance behind Google Cloud IAP. IAP accepts JWTs signed by a service account with aud set to the app URL, and accepts them in Proxy-Authorization (IAP programmatic auth). This works even when IAP uses the Google-managed OAuth client. Vercel documents the GCP federation setup in Connect to GCP.

via @dcramer.

--

View Session [Sentry]

Lenguaje dominante
TypeScript
Estrellas
397
Forks
43
Merge medio
8 h 28 min
PR fusionados (30 d)
764

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de getsentry/junior

Todos los issues de getsentry/junior

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.