[Feature Request] Allow a Connection to use mTLS for encryption and a bearer (JWT/API key) for authN/Z simultaneously

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

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
功能
描述清晰度
描述清楚
活跃度
活跃
技术栈
go
领域
authentication, backend

调研方向

Read the Connection CRD CEL rule and the client-auth builder paths named in the issue: fetchClientUsingMTLSSecret, fetchClientUsingAPIKeySecret, and getClientOptions. Trace how the CRD values reach TLS and credentials, then check the related tests. Done means a Connection can provide both client mTLS and bearer credentials, with existing single-credential behavior still covered.

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

描述

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

We run a self-hosted Temporal frontend that enforces requireClientAuth (mTLS, used for
encryption / client-cert gate) AND has application-layer authorization enabled (default
Authorizer + default JWT ClaimMapper, permissions claim in <namespace>:<role> form). Every
caller is expected to present BOTH a client certificate (mTLS) and a JWT bearer (for authZ).

The Worker Controller cannot connect in this setup. A Connection accepts either
mutualTLSSecretRef OR apiKeySecretRef, enforced as mutually exclusive by a CRD CEL rule, and
the controller builds its client auth in two mutually-exclusive branches:

  • fetchClientUsingMTLSSecret → { tls: <client cert>, credentials: nil }
  • fetchClientUsingAPIKeySecret → { tls: <serverName + CA only, no client cert>, credentials: <api key> }

So an mTLS client cert and a bearer token can never be presented together. With JWT authorization
enabled on the frontend, an mTLS-only controller receives empty claims (the default JWT
ClaimMapper returns empty Claims when no bearer is present) and is denied on every AccessWrite
API — even though our mTLS is valid and our authZ model already works for all other clients.

Describe the solution you'd like

Allow a Connection to carry BOTH an mTLS client credential (encryption) AND a bearer credential
(JWT / API key, for authN/Z) at the same time. Concretely:

  • relax the mutualTLSSecretRef XOR apiKeySecretRef CEL constraint so both can be set;
  • in the client-auth builder, combine the mTLS tls.Config (client cert) with
    opts.Credentials (bearer) rather than choosing one branch.

This matches what the Temporal Go SDK already supports: Options.ConnectionOptions.TLS and
Options.Credentials are independent fields and can both be set. The server likewise supports
mTLS-for-encryption together with JWT-for-authorization. The only place the two are mutually
exclusive is the controller's Connection model.

Additional context
  • Chart / controller version: 0.32.0 (appVersion 1.13.0).
  • Server: self-hosted, authorization enabled (default Authorizer + default JWT ClaimMapper,
    requireClientAuth: true on the frontend).
  • Source references: getClientOptions sets ConnectionOptions.TLS and Credentials
    independently; fetchClientUsingMTLSSecret / fetchClientUsingAPIKeySecret populate only one;
    the Connection CRD enforces the XOR via a CEL rule.
  • We suspect the current exclusivity reflects the Temporal Cloud model (API key alone + server
    TLS). Self-hosted deployments that combine mTLS encryption with JWT authZ need both at once.

If this is confirmed it is a blocking issue (we cannot use TWC) for security risk (of our security policies).

主要语言
Go
星标
198
派生
84
平均合并
2 天 19 小时
30 天内合并 PR
34

环境准备

  • 提供 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 摘要。