Skip to content

feat(reporter): render the IDP_* permission declaration from lerian-common, manager only - #2546

Draft
qnen wants to merge 1 commit into
fix/reporter-idp-schemafrom
feat/reporter-idp
Draft

qnen wants to merge 1 commit into
fix/reporter-idp-schemafrom
feat/reporter-idp

Conversation

@qnen

@qnen qnen commented Oct 16, 2026

Copy link
Copy Markdown
Contributor

Pull Request Type

  • Reporter

Draft: depende de dois PRs.

  1. fix(reporter): accept the IDP_* declaration keys in the configmap schema #2544 (schema): este branch é empilhado sobre ele, e a base deste PR é fix/reporter-idp-schema. Quando o fix(reporter): accept the IDP_* declaration keys in the configmap schema #2544 entrar, retargetar para main.
  2. Release do lerian-common (feat(common): add the permission declaration (IDP_*) env and secret helpers #2543, que adiciona lerian-common.idp.*): a dependência lerian-common-helm continua em 2.3.0, que ainda não tem os helpers, então o render deste branch falha até a troca. Quando o 2.4.0 for publicado: trocar version: "2.3.0" por "2.4.0" no Chart.yaml, rodar helm dependency update (Chart.lock) e tirar do draft.

Problema

  • O ConfigMap do manager emite IDP_* pelo range genérico de manager.configmap, sem default nem global.
  • O range do secrets de topo escreve IDP_M2M_CLIENT_ID/_SECRET no Secret do manager e no do worker (worker/secrets.yaml:36). Só o manager declara, então a credencial vai para um pod que não a usa.

O que muda

  • templates/manager/configmap.yaml: inclui lerian-common.idp.env. Precedência: manager.configmap > manager.extraEnvVars (legado) > common.configmap > global.idp.{declarationEnabled,host}. IDP_DECLARATION_ENABLED sempre sai (default "false"); IDP_HOST só quando setado. O range de manager.configmap e o passthrough de extraEnvVars pulam as duas chaves.
  • templates/_helpers.tpl: IDP_DECLARATION_ENABLED/IDP_HOST entram na lista $explicit do reporter.commonConfigmapData, para common.configmap nunca as emitir (o que duplicaria a chave no manager e as levaria ao worker).
  • templates/manager/secrets.yaml: o par sai do range e vem de lerian-common.idp.secret (modo data, cada chave só quando setada).
  • templates/worker/secrets.yaml: o range pula o par, que deixa de chegar ao worker.
  • values.yaml / README: global.idp e a seção "Access Manager Permission Declaration (manager)".
  • tests/test_idp_declaration.py: defaults, gate ligado (só manager, worker limpo), extraEnvVars legado e global.idp.host. Falha no chart atual (verificado) e passa com a mudança.

Compatibilidade

  • Render sem valores novos: só aparece IDP_DECLARATION_ENABLED: "false" no ConfigMap do manager.
  • Quem já passa as chaves por manager.configmap (o lerian-internal-gitops#3458) ou manager.extraEnvVars mantém os mesmos valores, sem chave duplicada.
  • O Secret do worker perde IDP_M2M_*. O worker não lê essas chaves, porque não declara permissões. Mesmo assim, é a única remoção, e fica aqui para a revisão confirmar. Release esperado: minor.

Teste local

helm v3.16.4, cópia do chart com lerian-common-helm apontando para o lerian-common do #2543 via file:// (só para teste, não commitado), comparada com o chart do #2544:

Caso Resultado
fixture de CI (helm-render-values/reporter.yaml) diff: só IDP_DECLARATION_ENABLED: "false" no ConfigMap do manager
values do benedita dev-st do #3458 ConfigMap do manager: mesmos valores, agora pelo helper; Secret do manager: o mesmo par; Secret do worker: sem IDP_M2M_*
values do anacleto chaos dev-st do #3458 igual, sem creds
manager.extraEnvVars.IDP_HOST + FOO host pelo helper, FOO no passthrough, sem duplicata
common.configmap.IDP_HOST + manager.configmap.IDP_DECLARATION_ENABLED=true manager com "true" e o host de common; worker sem IDP
global.idp.host + manager.extraEnvVars.IDP_HOST extraEnvVars vence

helm lint: 0 falhas. tests/test_idp_declaration.py e tests/test_crm_config.py: passam. validate-helm-charts --strict: 0 violações.

🤖 Generated with Claude Code

…ommon, manager only

The manager ConfigMap ranged IDP_DECLARATION_ENABLED/IDP_HOST straight
from manager.configmap, and the top-level secrets range wrote the
IDP_M2M_CLIENT_ID/_SECRET pair into BOTH the manager and the worker
Secret, although only the manager declares.

- Manager ConfigMap: include lerian-common.idp.env, resolved as
  manager.configmap > manager.extraEnvVars (legacy) > common.configmap
  > global.idp.{declarationEnabled,host}. IDP_DECLARATION_ENABLED is
  always rendered (default "false"), IDP_HOST only when set. The
  manager.configmap range and the extraEnvVars passthrough skip both
  keys, and reporter.commonConfigmapData lists them as explicit so
  common.configmap never emits them (nor reaches the worker).
- Manager Secret: the pair comes from lerian-common.idp.secret (data
  mode, each key only when set); the top-level range skips it.
- Worker Secret: skip the pair, so the declaration credentials no
  longer reach the worker.
- Document global.idp and the contract; add tests/test_idp_declaration.py.

Requires the lerian-common release that ships lerian-common.idp.*; the
lerian-common-helm dependency must move from 2.3.0 to it before merge.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Oct 16, 2026

Copy link
Copy Markdown

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Comment @coderabbitai help to get the list of available commands.

@lerian-studio-midaz-push-bot

Copy link
Copy Markdown
Contributor

Chart image references

1 of 1 chart(s) did not pass. A chart published while it points at an image that does not exist installs into ImagePullBackOff.

chart verified verdict
reporter 0 could not verify — see the run log
Every reference checked

reporter

no image references


🖼️ View full logs

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant