Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Support Kubernetes Service Account Tokens as an auth mode for Connection (controller + worker pods)

Aperta
  • Qualcosa non va?
#515 6 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@kriyanshii ci sta già lavorando.

Dal 12/10/2026.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go, kubernetes
Ambito
authentication, backend

Direzione di ricerca

Inizia da ConnectionSpec e clientpool.go, in particolare dal percorso apiKeySecretRef esistente che usa sdkclient.NewAPIKeyDynamicCredentials. Segui i punti di ingresso per la generazione dei template dei pod del controller e dei worker per capire dove vengono configurati i volumi projected dei service account, i mount e le variabili d’ambiente. Il lavoro è completato quando l’autenticazione del controller usa un token projected e i pod dei worker generati ricevono impostazioni TokenRequest configurabili senza credenziali statiche.

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

Descrizione

rbac

Is your feature request related to a problem? Please describe.

Today Connection supports exactly two mutually-exclusive auth modes: mutualTLSSecretRef
and apiKeySecretRef. Both require a long-lived, static Kubernetes Secret — a client cert/key
pair for mTLS, or a bearer token for API keys. For self-hosted Temporal running on Kubernetes,
this means:

  • The controller itself holds a static credential to make control-plane calls (register worker
    deployment versions, check drainage, etc.).
  • Worker pods get that same static credential injected as an env var at pod creation time, with
    no rotation until the pod restarts.

For teams already running Workload Identity / IRSA / OIDC-federated auth elsewhere in their
Kubernetes platform (no static keys, short-lived tokens, automatic rotation), this is a step
backward — it reintroduces exactly the kind of long-lived Secret that Workload Identity patterns
are meant to eliminate. It also means every rotation of the underlying cert/key requires updating
a Secret and waiting for the controller/pods to notice, rather than tokens refreshing themselves
transparently.

This isn't hypothetical — worker-side JWT auth against Temporal keeps coming up in the community:

Describe the solution you'd like

Add a third auth mode, e.g. serviceAccountToken, to ConnectionSpec, alongside the existing
mutualTLSSecretRef / apiKeySecretRef. This would rely on projected Kubernetes SA tokens
(TokenRequest API) rather than a static Secret, and splits cleanly into two independent pieces:

1. Controller's own connection (control plane)
The controller already runs as a pod with its own ServiceAccount. Instead of reading a static
Secret, it would read its own pod's projected SA token (refreshed automatically by kubelet) and
use it as a bearer token via sdkclient.NewAPIKeyDynamicCredentials, the same mechanism already
used for the apiKeySecretRef path in clientpool.go. This is a self-contained change — no new
pod-injection logic needed, since the controller's own pod spec is under the cluster operator's
control already.

2. Worker pods (data plane)
When Connection.spec.authMode: ServiceAccountToken is set, the controller would inject into
every worker pod template it generates:

  • a projected volume with a serviceAccountToken source (configurable audience,
    expirationSeconds)
  • a volumeMount at a well-known path
  • an env var pointing at that path (e.g. TEMPORAL_API_KEY_FILE) instead of the current
    TEMPORAL_API_KEY=<value> injection

Example spec:

apiVersion: temporal.io/v1alpha1
kind: Connection
metadata:
  name: my-temporal-connection
spec:
  hostPort: temporal-frontend.temporal-system:7233
  authMode: ServiceAccountToken
  serviceAccountToken:
    audience: temporal
    expirationSeconds: 3600

Worker pods would need no manual volume/env config — just a serviceAccountName on the pod
template, same as today.

Additional context

  • This mode would only be meaningful for self-hosted Temporal — it requires the server to be
    configured with a JWT ClaimMapper validating tokens against the cluster's OIDC issuer/JWKS.
    Temporal Cloud's auth model doesn't support this today, so this would not replace
    apiKeySecretRef as the recommended mode there.
  • The controller can guarantee "a fresh token is on disk," but whether the worker process
    actually re-reads that file per-connection (vs. caching it once at startup) is up to the
    worker's own SDK client construction — e.g. Go SDK's NewAPIKeyDynamicCredentials callback
    pattern.
  • For multi-cluster setups (workers on EKS/AKS/GKE all pointing at one Temporal cluster), the
    server-side ClaimMapper would need to trust multiple clusters' OIDC issuers — worth surfacing
    in docs rather than assuming a single-issuer setup.
Lingua principale
Go
Stelle
197
Fork
82
Merge medio
3g 40m
PR unite (30g)
35

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

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 temporalio/temporal-worker-controller

Tutte le issue di temporalio/temporal-worker-controller

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.