Support workload identity federation for plugin credentials
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
- Ambito
- authentication, backend-api-design, security
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
credentialssupport onlyoauth-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-headersare 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 itsexpiresAt. - 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
Authorizationfor their own auth (Redash:Authorization: Key …). The proxy credential then has to go inProxy-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 withaud: https://<host>/*), and target header. - Configurable target header, including
Proxy-Authorization, used alongside staticapi-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.
--
- Lingua principale
- TypeScript
- Stelle
- 397
- Fork
- 43
- Merge medio
- 8h 28m
- PR unite (30g)
- 764
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di getsentry/junior
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di getsentry/junior
Issue simili
-
area:tooling good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
interledger/publisher-tools#1007 ·
I maintainer di solito rispondono entro 1 giorno
-
priority/medium roadmap/v1.1.1 stakeholder/rapr type/bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
databrickslabs/ontos#1420 ·
I maintainer di solito rispondono entro 3 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
vercel-labs/just-bash#756 ·
I maintainer di solito rispondono entro 1 giorno
-
area: ci good first issue
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
interledger/web-monetization-extension#1555 ·
I maintainer di solito rispondono entro 1 giorno
-
🐞 bug 🧐 unconfirmed
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
Tencent/tdesign-vue-next#7056 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno