[Bug] Gate inputFrom.configMapKeyRef fails with the default chart: the manager role has no ConfigMap permission

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

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

関連するプルリクエストがすでにマージされています。

  • #650 @wankhede04 による — マージ済み

評価

難易度
3/5
見積もり時間
半日
初心者へのやさしさ
25/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
go, helm, kubernetes
領域
authorization, infrastructure

調査の方向性

The read happens in internal/controller/genplan.go, which calls r.Client.Get on a ConfigMap, and the manager role lives in the chart's RBAC templates. Check whether the cache-backed client needs an informer for corev1.ConfigMap and whether the role needs get, or get;list;watch. Done when a user holding only get on ConfigMaps can resolve a configMapKeyRef gate input. PR #650 is already open against this, so discuss the approach there before starting.

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

説明

rbac

What happens

A TemporalWorkerDeployment whose rollout gate reads its input from a ConfigMap:

  rolloutStrategy:
    gate:
      workflowType: ...
      inputFrom:
        configMapKeyRef:
          name: gate-input
          key: payload.json

never gets its gate input on a cluster that enforces RBAC with the chart's default roles.

Why

internal/controller/genplan.go reads the ConfigMap with r.Client.Get. The manager's client is cache-backed, so the
first Get starts a ConfigMap informer, which needs list and watch on ConfigMaps. The generated manager role has no
configmaps rule at all. The only ConfigMap rule in the chart is the leader-election Role in the release namespace.

secretKeyRef works because the role grants get;list;watch on secrets.

The feature is documented (docs/configuration.md, "Gate workflow input details") and was added in #152.

How I checked

Against an API server with --authorization-mode=RBAC, as a user holding only get on ConfigMaps:

  • a cache-backed Get of the ConfigMap blocks until the informer-sync timeout and fails with
    Timeout: failed waiting for *v1.ConfigMap Informer to sync
  • a direct LIST is forbidden, as expected

I have not reproduced it on a full chart install. It is easy to miss on clusters where the controller's
ServiceAccount is broadly permissive.

Proposed fix

Add get on ConfigMaps to the manager role and read ConfigMaps directly (cache bypass for corev1.ConfigMap in
the manager's client options), so the controller needs no list or watch and does not cache every ConfigMap.

The alternative is get;list;watch, like secrets. That is one line, but it caches all ConfigMaps in the watched
namespaces. Which do you prefer? Happy to send the PR either way.

主要言語
Go
スター
198
フォーク
84
平均マージ
2日 18時間
マージ済み PR（30日）
35

環境構築

  • 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 を短くまとめたダイジェスト。