Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Feature Request] Consider using explicit configuration for temporal api key

オープン
  • 何か問題がありますか？
#375 コメント 5 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@kriyanshii がすでに取り組んでいます。

2026年8月31日 から。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go, kubernetes
領域
devops, infrastructure

調査の方向性

docs/configuration.md から始めて、TemporalWorkerDeployment の設定と、controller による secret および環境変数の処理を調査します。明示的な secret/API key 参照、競合エラー、ドキュメントがどのように機能すべきかを明確にします。現在の暗黙的な規約に依存せずに、提案する動作と設定が定義されていれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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

TLDR; it doing weird magic stuff with regards to secrets management and that makes maintenance hard.

I am an application developer and tend to touch k8s the most on our team. Note that I am not the person who set the controller up in our environment. I am aware of it and have had my struggles with it, but its not at the front of my mind in general and I usually am just working with kubernetes abstractions.

In this situation I needed to rotate our temporal key. I look at our application secrets and notice that we have a TEMPORAL_API_KEY in our secrets (which are used via secretRef). I keep updating it checking it, triple checking it, rolling containers, no matter what I do, whenever I exec into the container I see the old api key.

Eventually I noticed we have another kubernetes secret named temporal-api-token that does have the old key in it, but the key is under the api-key value, not TEMPORAL_API_KEY which is what our code uses. I search all our helm charts, our entire codebase for either temporal-api-token or api-key and I find nothing in there. The way this is included in our helm chart it just creates an env var named api-key which everything ignores.

Eventually I track it down. What is happening is that we should not have had a TEMPORAL_API_KEY in secrets at all, that is something that the temporal worker controller creates. It just implicitly assumes that you have a secret named temporal-api-token, and that it has that api-key in it. None of it explicit, its all by convention and it then overwrites the actual environment variables when it starts. This is the only place I can find where any of this stuff is explained and it's frankly really confusing what you're supposed to do and what the options are.

All in all, this was a solid 3 hours of confusion and pulling my hair out over what might be going on.

Describe the solution you'd like

My recommendation for yall:

Document this a hell of a lot more clearly in a lot more places
Error if the TEMPORAL_API_KEY already exists and is going to get overwritten
Explicitly pass in the secret/api-key that will be used into the TemporalWorkerDeployment, This is not a spot for convention-over-configuration. I predict a lot of scenarios where someone sees that secret, finds no reference to it at all in their yaml templates, figures it is some sort of vestigial thing and deletes it then next time the containers restart they fail to come up.

Additional Context

Originally posted in slack

主要言語
Go
スター
197
フォーク
82
平均マージ
3日 2時間
マージ済み PR（30日）
31

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

temporalio/temporal-worker-controller のほかの issue

temporalio/temporal-worker-controller の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。