Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#515 6 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@kriyanshii 已经在做这个了。

开始于 2026年10月12日。

评估

难度
5/5
预计耗时
一周以上
新手友好度
48/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
go, kubernetes
领域
authentication, backend

调研方向

从 ConnectionSpec 和 clientpool.go 开始，尤其关注使用 sdkclient.NewAPIKeyDynamicCredentials 的现有 apiKeySecretRef 路径。跟踪 controller 和 worker pod-template 生成的入口点，以了解 projected service-account volume、mount 和环境变量在哪里配置。完成标准是 controller 认证使用 projected token，并且生成的 worker pod 在没有静态凭据的情况下接收可配置的 TokenRequest 设置。

由索引模型根据 Issue 内容生成。

描述

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.
主要语言
Go
星标
197
派生
82
平均合并
3 天 40 分钟
30 天内合并 PR
35

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

temporalio/temporal-worker-controller 的其他 Issue

查看 temporalio/temporal-worker-controller 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。