From dc510205d130746c2cffdc2c93c5ed56d2965aa4 Mon Sep 17 00:00:00 2001 From: deploy Date: Thu, 24 Sep 2026 22:39:40 +0000 Subject: [PATCH] feat(tenant): Role por tenant para os dois Secrets que o provisionamento le MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit db-credentials (a senha do papel) e -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. --- .../16-rolebinding-provisionamento.yaml | 37 +++++++++++++++++++ .../16-rolebinding-provisionamento.yaml | 37 +++++++++++++++++++ .../16-rolebinding-provisionamento.yaml | 37 +++++++++++++++++++ .../plataforma/16-rbac-provisionamento.yaml | 7 ++-- 4 files changed, 114 insertions(+), 4 deletions(-) diff --git a/moldes/consolidado/16-rolebinding-provisionamento.yaml b/moldes/consolidado/16-rolebinding-provisionamento.yaml index 9552494..713a08e 100644 --- a/moldes/consolidado/16-rolebinding-provisionamento.yaml +++ b/moldes/consolidado/16-rolebinding-provisionamento.yaml @@ -20,3 +20,40 @@ roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: atm-provisionamento-tenants + +--- +# Os DOIS Secrets que o provisionamento le neste namespace, pelo nome. +# +# Role por tenant, e nao regra no ClusterRole, porque os nomes dependem do +# tenant e `resourceNames` nao aceita curinga. A alternativa seria dar `get` em +# QUALQUER Secret do namespace — e ai o provisionamento passaria a poder ler a +# chave Asaas DO CLIENTE, que e dele e nao nossa. +# +# db-credentials a senha do papel no Postgres, que a etapa BANCO_CRIADO +# precisa para dar a senha ao papel e ao pool +# {{TENANT}}-tls so a EXISTENCIA, que e como a etapa DNS_PUBLICADO sabe que +# o cert-manager terminou de emitir +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + name: atm-provisionamento-segredos + namespace: {{TENANT}}-prod +rules: + - apiGroups: [""] + resources: ["secrets"] + verbs: ["get"] + resourceNames: ["db-credentials", "{{TENANT}}-tls"] +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: atm-provisionamento-segredos + namespace: {{TENANT}}-prod +subjects: + - kind: ServiceAccount + name: atm-provisionamento + namespace: plataforma-prod +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: Role + name: atm-provisionamento-segredos diff --git a/tenants/escolinha-de-teste-2/16-rolebinding-provisionamento.yaml b/tenants/escolinha-de-teste-2/16-rolebinding-provisionamento.yaml index 27b6b19..2978773 100644 --- a/tenants/escolinha-de-teste-2/16-rolebinding-provisionamento.yaml +++ b/tenants/escolinha-de-teste-2/16-rolebinding-provisionamento.yaml @@ -20,3 +20,40 @@ roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: atm-provisionamento-tenants + +--- +# Os DOIS Secrets que o provisionamento le neste namespace, pelo nome. +# +# Role por tenant, e nao regra no ClusterRole, porque os nomes dependem do +# tenant e `resourceNames` nao aceita curinga. A alternativa seria dar `get` em +# QUALQUER Secret do namespace — e ai o provisionamento passaria a poder ler a +# chave Asaas DO CLIENTE, que e dele e nao nossa. +# +# db-credentials a senha do papel no Postgres, que a etapa BANCO_CRIADO +# precisa para dar a senha ao papel e ao pool +# escolinha-de-teste-2-tls so a EXISTENCIA, que e como a etapa DNS_PUBLICADO sabe que +# o cert-manager terminou de emitir +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + name: atm-provisionamento-segredos + namespace: escolinha-de-teste-2-prod +rules: + - apiGroups: [""] + resources: ["secrets"] + verbs: ["get"] + resourceNames: ["db-credentials", "escolinha-de-teste-2-tls"] +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: atm-provisionamento-segredos + namespace: escolinha-de-teste-2-prod +subjects: + - kind: ServiceAccount + name: atm-provisionamento + namespace: plataforma-prod +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: Role + name: atm-provisionamento-segredos diff --git a/tenants/escolinha-de-teste/16-rolebinding-provisionamento.yaml b/tenants/escolinha-de-teste/16-rolebinding-provisionamento.yaml index 49f6b8f..e2cd06b 100644 --- a/tenants/escolinha-de-teste/16-rolebinding-provisionamento.yaml +++ b/tenants/escolinha-de-teste/16-rolebinding-provisionamento.yaml @@ -20,3 +20,40 @@ roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: atm-provisionamento-tenants + +--- +# Os DOIS Secrets que o provisionamento le neste namespace, pelo nome. +# +# Role por tenant, e nao regra no ClusterRole, porque os nomes dependem do +# tenant e `resourceNames` nao aceita curinga. A alternativa seria dar `get` em +# QUALQUER Secret do namespace — e ai o provisionamento passaria a poder ler a +# chave Asaas DO CLIENTE, que e dele e nao nossa. +# +# db-credentials a senha do papel no Postgres, que a etapa BANCO_CRIADO +# precisa para dar a senha ao papel e ao pool +# escolinha-de-teste-tls so a EXISTENCIA, que e como a etapa DNS_PUBLICADO sabe que +# o cert-manager terminou de emitir +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + name: atm-provisionamento-segredos + namespace: escolinha-de-teste-prod +rules: + - apiGroups: [""] + resources: ["secrets"] + verbs: ["get"] + resourceNames: ["db-credentials", "escolinha-de-teste-tls"] +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: atm-provisionamento-segredos + namespace: escolinha-de-teste-prod +subjects: + - kind: ServiceAccount + name: atm-provisionamento + namespace: plataforma-prod +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: Role + name: atm-provisionamento-segredos diff --git a/tenants/plataforma/16-rbac-provisionamento.yaml b/tenants/plataforma/16-rbac-provisionamento.yaml index 440e869..b333c63 100644 --- a/tenants/plataforma/16-rbac-provisionamento.yaml +++ b/tenants/plataforma/16-rbac-provisionamento.yaml @@ -62,10 +62,9 @@ rules: # `resourceNames` amarra ao NOME: este ClusterRole nao le `asaas-credentials` # nem nenhum outro Secret do cliente. E o RoleBinding do molde o limita aos # namespaces de tenant — nao ha binding cluster-wide. - - apiGroups: [""] - resources: ["secrets"] - verbs: ["get"] - resourceNames: ["db-credentials"] + # A leitura de Secret do tenant NAO esta aqui: ela e uma Role por tenant, no + # molde, porque `{{TENANT}}-tls` depende do nome e `resourceNames` nao aceita + # curinga. Ver moldes/consolidado/16-rolebinding-provisionamento.yaml. --- # O userlist do PgBouncer, que a etapa BANCO_CRIADO acrescenta.