Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Cerrado
  • ¿Algo no está bien?
#655 1 comentario 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
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
backend, security

Línea de trabajo

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.

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

Descripción

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.
Lenguaje dominante
Go
Estrellas
197
Forks
79
Merge medio
3 d 13 h
PR fusionados (30 d)
25

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

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

Todos los issues de temporalio/temporal-worker-controller

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.