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

Cerrado
  • ¿Algo no está bien?
#649 5 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Ya se ha fusionado un pull request relacionado.

  • #650 de @wankhede04 — fusionado

Evaluación

Dificultad
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go, helm, kubernetes
Área
authorization, infrastructure

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Go
Estrellas
198
Forks
84
Merge medio
2 d 18 h
PR fusionados (30 d)
35

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de temporalio/temporal-worker-controller

Todos los issues de temporalio/temporal-worker-controller

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.