Support workload identity federation for plugin credentials

Aperta
#3,122 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
aws, azure, gcp, typescript

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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]

Lingua principale
TypeScript
Stelle
397
Fork
43
Merge medio
8h 28m
PR unite (30g)
764

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di getsentry/junior

Tutte le issue di getsentry/junior

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.