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

Abierto
  • ¿Algo no está bien?
#515 7 comentarios 1 reacción 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@kriyanshii ya está trabajando en esto.

Desde el 12/10/2026.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go, kubernetes
Área
authentication, backend

Línea de trabajo

Comienza con ConnectionSpec y clientpool.go, especialmente con la ruta existente apiKeySecretRef que usa sdkclient.NewAPIKeyDynamicCredentials. Sigue los puntos de entrada de generación de plantillas de pods del controlador y de los workers para entender dónde se configuran los volúmenes de cuentas de servicio proyectados, los montajes y las variables de entorno. Se considera terminado cuando la autenticación del controlador usa un token proyectado y los pods de worker generados reciben configuraciones de TokenRequest configurables sin credenciales estáticas.

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

Descripción

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.
Lenguaje dominante
Go
Estrellas
198
Forks
84
Merge medio
2 d 19 h
PR fusionados (30 d)
34

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.