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

feat: support file-based / external API key credentials (API key counterpart of #311)

Aperta
  • Qualcosa non va?
#449 10 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@jaypipes ci sta già lavorando.

Dal 23/7/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

rbac

Problem

We authenticate to Temporal Cloud with API keys and run the controller on GKE.
Our security policy requires secrets to be held in GCP Secret Manager and retrieved by the
workload at runtime, rather than stored as Kubernetes Secrets in etcd.

Today Connection accepts credentials only via apiKeySecretRef, a SecretKeySelector that
must name a Kubernetes Secret in the same namespace. The controller resolves it through the
Kubernetes API, and it also injects TEMPORAL_API_KEY into managed worker pods via
secretKeyRef. There is no way to supply the API key from a file, from a volume mounted by
the Secrets Store CSI driver, or from an external secret manager.

#311 proposes file-based credentials, but is explicitly scoped to mTLS. There is currently no
equivalent for API key auth, so organizations that standardize on API keys cannot benefit
from it.

Why this matters

  • The Secrets Store CSI driver can mount secrets into pods without creating a Kubernetes
    Secret     (secretObjects is optional). That pattern is unusable with the controller today,
    because credentials are resolved through the API server rather than through the pod-spec
    layer.
  • Same RBAC motivation as #311: the chart grants secrets get/list/watch in a ClusterRole.
    On a cluster shared by multiple teams, that is considerably wider than the controller's
    actual need. A file-based mode would let deployers drop the rule entirely.
  • Temporal's own guidance recommends retrieving API keys from a key management system rather
    than hardcoding them, and the Go SDK already supports this through
    client.NewAPIKeyDynamicCredentials.

Proposed

An alternative to apiKeySecretRef on ConnectionSpec:

spec:
  hostPort: "us-east-1.aws.api.temporal.io:7233"
  apiKeyFile:
    path: /etc/temporal/api-key

The controller would read the file on each use. Since #301 already made the API key re-read
per RPC via NewAPIKeyDynamicCredentials, this is largely a change of source rather than a
change of lifecycle.

When this mode is used, the controller would skip credential injection into worker pods and
leave credential delivery to the pod-spec layer (volumes / CSI), consistent with the scope
of #311.

Related

  • #311 — file-based mTLS credentials (the mTLS counterpart of this request)
  • #246 — controller as a library (would also address this, by allowing a pre-configured client)
  • #301 — the API key is already re-read per RPC
Lingua principale
Go
Stelle
197
Fork
79
Merge medio
5g 7h
PR unite (30g)
29

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.