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

[Feature Request] Option to not propagate the Connection credential into worker pods / separate controller and worker credentials

Chiusa
  • Qualcosa non va?
#655 1 commento 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
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
backend, security

Direzione di ricerca

Start at ApplyControllerPodSpecModifications and the deployment builder call mentioned in the issue, then trace how workerOptions.connectionRef supplies credentials to controller management calls and worker pods. Compare the Secret mount and environment variable paths for mTLS and API keys. Done when a documented option or separate references let controller management and worker runtime use distinct credentials, with the resulting pod configuration covered.

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

Descrizione

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

For a given WorkerDeployment, the controller resolves the Connection via
workerOptions.connectionRef and uses that credential for its OWN management calls
(SetWorkerDeploymentCurrentVersion / SetWorkerDeploymentRampingVersion /
DeleteWorkerDeploymentVersion — all AccessWrite). It then mounts the SAME
mutualTLSSecretRef Secret (tls.crt / tls.key) into the generated worker pods and sets
TEMPORAL_TLS_CLIENT_* (via ApplyControllerPodSpecModifications, called unconditionally).

When Temporal authorization is enabled, the controller needs namespace write (versioning /
routing). Because the worker pods inherit the SAME Connection credential, the application code
running inside the worker pod can read a client certificate that carries namespace-write, and
can therefore act on any workflow in that Temporal namespace — more than a worker needs, and the
credential is exposed to arbitrary application code in the pod. This breaks least-privilege: the
controller's management identity and the workers' runtime identity are the same.

Describe the solution you'd like

A way to give the controller a management credential distinct from what is mounted into the
worker pods, within a single WorkerDeployment. For example, any of:

  • an option to disable propagation of the Connection Secret into worker pods (e.g. when the
    worker supplies its own credential out-of-band);
  • a separate controllerConnectionRef (controller management) vs workerConnectionRef (mounted
    into worker pods), so the two identities/permissions can differ;
  • documented guidance that the intended isolation unit is "one Temporal namespace + one
    Connection per workload", if finer separation is out of scope.
Additional context
  • Chart / controller version: 0.32.0 (appVersion 1.13.0).
  • Source references: ApplyControllerPodSpecModifications (mounts mutualTLSSecretRef +
    TEMPORAL_TLS_CLIENT_* into worker containers) is called unconditionally from the deployment
    builder; the controller client and the worker pods use the same Connection.
  • Observed with requireClientAuth + JWT authorization enabled on the frontend; the concern also
    applies to the apiKeySecretRef path (the API key is injected into the worker pod as
    TEMPORAL_API_KEY).
  • Related: this is the same Connection auth-model surface as the mTLS+bearer feature request
    above; they may be considered together.
Lingua principale
Go
Stelle
197
Fork
79
Merge medio
3g 13h
PR unite (30g)
25

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.