diff --git a/tenants/plataforma/82-servico-captacao.yaml b/tenants/plataforma/82-servico-captacao.yaml index 29f26ea..cb5eb09 100644 --- a/tenants/plataforma/82-servico-captacao.yaml +++ b/tenants/plataforma/82-servico-captacao.yaml @@ -100,7 +100,7 @@ spec: # `@CrossOrigin` aqui aceita UMA origem: o placeholder vira string # literal, entao virgula nao separa em duas. Se a LP for publicada # noutro host, este valor muda junto ou o formulario toma CORS. - - { name: CAPTACAO_ORIGEM, value: "https://plataforma.athleticmap.influxdigital.com.br" } + - { name: CAPTACAO_ORIGEM, value: "https://plataforma.athleticmap.com" } - { name: CAPTACAO_RETENCAO_MESES, value: "24" } # P5.1 — o token do webhook de ASSINATURA. Sem ele o endpoint # RECUSA TUDO, de proposito, e o log diz exatamente isso. O mesmo @@ -138,8 +138,62 @@ spec: # 2026-09-22. Escrever num diretorio temporario que ninguem commita # daria a impressao de que a etapa funcionou. - { name: PROVISIONAMENTO_GITOPS, value: "/gitops" } + # P5.3 — o repositorio remoto para onde o commit e EMPURRADO. + # + # O nome DE DENTRO do cluster, e nao o `git..nip.io` que se usa + # de fora: o de fora sai do cluster e volta, e a NetworkPolicy de + # egress (19-netpol-gitea) permite o caminho interno, nao o externo. + # + # `gitea-http` e headless (ClusterIP None), entao o DNS devolve o IP + # do POD. Isso e o que faz a netpol por `podSelector` funcionar aqui + # — `ipBlock` com ClusterIP nao funciona atravessando namespace, + # porque o k3s avalia a politica DEPOIS do DNAT. + - { name: PROVISIONAMENTO_GITOPS_URL, + value: "http://gitea-http.gitea.svc:3000/atmadmin/athletic-map-deploy.git" } + # P5.3 — quem empurra. ESTA CREDENCIAL IMPLANTA EM PRODUCAO: o + # ApplicationSet tem gerador de diretorio sobre `tenants/*` com + # selfHeal, entao a pasta empurrada vira Application e e aplicada + # sozinha. Por isso e um usuario proprio do Gitea, com escrita so + # neste repositorio, e um TOKEN revogavel — nao a conta atmadmin. + - name: PROVISIONAMENTO_GITOPS_USUARIO + valueFrom: + secretKeyRef: { name: provisionamento-credentials, key: gitops-usuario } + - name: PROVISIONAMENTO_GITOPS_SENHA + valueFrom: + secretKeyRef: { name: provisionamento-credentials, key: gitops-senha } + # P5.4 — a Admin API do Keycloak, para criar o realm do tenant novo. + # + # `AdminDoKeycloak` pega token por `grant_type=password` no client + # `admin-cli` do realm `master`, entao isto e um usuario DE LA, e nao + # do realm `athleticmap`. + # + # Hoje pode ser o admin do master, que pode tudo. O certo e um + # usuario de servico com `create-realm` e nada mais — esta no diario. + - name: KEYCLOAK_ADMIN_USUARIO + valueFrom: + secretKeyRef: { name: provisionamento-credentials, key: keycloak-admin-usuario } + - name: KEYCLOAK_ADMIN_SENHA + valueFrom: + secretKeyRef: { name: provisionamento-credentials, key: keycloak-admin-senha } - { name: PROVISIONAMENTO_MOLDE, value: "/gitops/moldes/consolidado" } - { name: PROVISIONAMENTO_PLANO_PADRAO, value: "bronze" } + # P5.8 — a chave do Asaas, para CRIAR o link de assinatura. + # + # E o mesmo Secret que o `servico-financeiro` usa, e por isso + # nao ha credencial nova a selar: muda so quem a le. Os dois + # fluxos continuam distintos — o financeiro cobra o ATLETA, este + # cobra o TENANT. + # + # `optional: true` de proposito: um ambiente sem Asaas sobe do + # mesmo jeito, e a venda que precisar da chave recusa nomeando a + # propriedade. Derrubar o pod tiraria do ar o provisionamento e a + # captura de lead, que nao dependem disso. + - name: ASAAS_API_KEY + valueFrom: + secretKeyRef: + name: asaas-credentials + key: api-key + optional: true - { name: CAPTACAO_LIMITE_POR_IP, value: "5" } # Destino do aviso ao comercial. Vazio = lead e gravado e o # aviso vira log sem PII. Preencher quando houver SMTP.