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.
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.
RBAC amarrado por resourceNames (db-credentials nos tenants, pgbouncer-userlist
so aqui), netpol do PgBouncer por ROTULO em vez de por nome, e a credencial de
administracao do Postgres compartilhado para o servico-captacao.
deploy