Pedi get/list em namespaces para a etapa ARGO_SINCRONIZADO provar que o
Argo aplicou. NAO FUNCIONA: o ClusterRole e ligado a conta por
RoleBinding POR TENANT, e RoleBinding so concede DENTRO do seu
namespace. `namespaces` e recurso de cluster, entao a resposta continua
negada -- e o que resolveria e um ClusterRoleBinding, porta bem mais
larga do que a pergunta.
A etapa passou a provar pelo Secret db-credentials do tenant, que
responde a mesma coisa e um pouco mais: para ele ser legivel o Argo teve
de criar namespace, Role, RoleBinding e SealedSecret, e o controlador
teve de abri-lo. Permissao que ninguem usa nao se pede.
A etapa ARGO_SINCRONIZADO concluia no `git push`, que e outra coisa:
entre empurrar e aplicar esta o ciclo do gerador de diretorio do
ApplicationSet. A etapa seguinte encontrava o namespace inexistente e
recebia 403 -- sem permissao dentro dele, a API nao diz "nao existe",
diz "nao pode" -- e queimava tentativas esperando por algo que nao era
trabalho dela.
get e list, so em namespaces. O que isto revela e o NOME dos namespaces,
para um servico que e justamente quem os cria.
O script de rotacao usou `bash -s` com o roteiro E a senha no mesmo stdin: o
`read` consumiu linha do proprio roteiro, e o Secret foi selado com lixo (54
caracteres). O pod nao tinha reiniciado, entao o e-mail continuava funcionando
pela variavel ja carregada — mas o proximo restart quebraria.
Volta ao selo que funciona. A senha nova sera aplicada pelo script corrigido.
A prova de ponta a ponta terminou. Com o bloco no ar, /planos devolvia bronze
mensal 5,00 contra anual 1.870,00 — e a landing page mostraria os dois lado a
lado.
A contratacao pela landing page. Aqui nao ha catch-all: caminho que nao esta
escrito nao existe — o endpoint respondeu vazio com a imagem ja no ar porque o
servico tinha a rota e o Ingress nao.
Vale para TODO tenant provisionado: eles nao tem Keycloak proprio, usam este,
um realm cada. O tema vem por ConfigMap e nao por imagem porque o login.ftl traz
as imagens em data URI — o ConfigMap e montado read-only sobre o diretorio e nao
sobra resources/ para o Keycloak servir.
O molde do tenant ja apontava para ca — a SPA em ATM_KC_URL e os tres runtimes
em ATM_ISSUER — e o host nao existia. O navegador batia em
ERR_CERT_AUTHORITY_INVALID e, passando por cima, em 404 do Traefik.
Nao e auth-plataforma para o cliente: o endereco aparece na barra dele durante
o login, e o nome do nosso tenant interno nao tem o que fazer ali.
A etapa BANCO_CRIADO reinicia o PgBouncer e espera ele voltar. Com 5, o backoff
da 155s — menos do que o pod novo levou nas tres medicoes de hoje, e os dois
clientes pagos precisaram de retomada a mao. Com 8 da 515s, dentro da janela.
So o hostname faz o Keycloak resolver esquema e porta a partir da requisicao.
O provisionamento chama a Admin API por dentro (http://keycloak:8080), e o link
do convite saiu http://auth-plataforma.athleticmap.com:8080 — o cliente clicava
e dava ERR_CONNECTION_TIMED_OUT.
O deny-cross-tenant libera 443 para a internet e nada mais. O Keycloak batia em
Network is unreachable na 587, e o erro que chegava ao provisionamento era
Failed to send execute actions email — que manda procurar no SMTP, nao na rede.
db-credentials (a senha do papel) e <tenant>-tls (so a existencia, que e como a
etapa DNS_PUBLICADO sabe que o cert-manager terminou). Por tenant porque o nome
do TLS depende dele e resourceNames nao aceita curinga — e dar get em qualquer
Secret do namespace deixaria o provisionamento ler a chave Asaas DO CLIENTE.
deploy