deploy
5633bd42ba
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.
117 lines
5.0 KiB
YAML
117 lines
5.0 KiB
YAML
# =============================================================================
|
|
# P5.6/P5.9 — a permissao que o provisionamento precisa nos tenants.
|
|
#
|
|
# ── O QUE O CODIGO FAZ (e nada alem disso) ──────────────────────────────────
|
|
#
|
|
# `ApiDoKubernetes`, no `servico-captacao`, faz exatamente duas coisas com o
|
|
# token do proprio pod:
|
|
#
|
|
# GET /apis/apps/v1/namespaces/<tenant>-prod/deployments/<nome>
|
|
# — esperar o rollout do tenant novo terminar (P5.6);
|
|
# PATCH /apis/apps/v1/namespaces/<tenant>-prod/deployments/<nome>/scale
|
|
# — suspender o cliente inadimplente, zerando replicas (P5.9).
|
|
#
|
|
# Sem estas regras a etapa falha com 403. No caso da suspensao, o 403 vem DEPOIS
|
|
# de o realm ja ter sido desligado: o cliente fica bloqueado com os pods de pe —
|
|
# gasta memoria, mas nenhum dado corre risco — e o evento fica FALHOU ate a
|
|
# permissao existir.
|
|
#
|
|
# ── POR QUE ClusterRole + RoleBinding, E NAO ClusterRoleBinding ─────────────
|
|
#
|
|
# O ClusterRole aqui e so a LISTA de verbos (um ClusterRole sem binding nao da
|
|
# acesso a nada). Quem concede e o RoleBinding, que vive DENTRO do namespace do
|
|
# tenant — um por tenant, em `tenants/<tenant>/16-rolebinding-provisionamento.yaml`.
|
|
# Com um ClusterRoleBinding, a plataforma passaria a ler e escalar Deployment de
|
|
# QUALQUER namespace, inclusive `kube-system` e `argocd`.
|
|
#
|
|
# Tenant novo entra pelo molde consolidado, que ja traz o RoleBinding.
|
|
#
|
|
# ── A ServiceAccount ────────────────────────────────────────────────────────
|
|
#
|
|
# Dedicada. Ate aqui o `servico-captacao` rodava com a `default` do namespace, e
|
|
# dar poder a `default` significa dar poder a QUALQUER pod que suba sem
|
|
# `serviceAccountName` — inclusive um pod de teste.
|
|
# =============================================================================
|
|
apiVersion: v1
|
|
kind: ServiceAccount
|
|
metadata:
|
|
name: atm-provisionamento
|
|
namespace: plataforma-prod
|
|
---
|
|
apiVersion: rbac.authorization.k8s.io/v1
|
|
kind: ClusterRole
|
|
metadata:
|
|
name: atm-provisionamento-tenants
|
|
rules:
|
|
# Esperar o rollout: so leitura.
|
|
- apiGroups: ["apps"]
|
|
resources: ["deployments"]
|
|
verbs: ["get"]
|
|
# Suspender e reativar: o subrecurso `scale` altera SO as replicas. Escrever no
|
|
# Deployment inteiro deixaria trocar imagem e variavel de ambiente.
|
|
- apiGroups: ["apps"]
|
|
resources: ["deployments/scale"]
|
|
verbs: ["get", "patch"]
|
|
# A senha do papel do tenant no Postgres.
|
|
#
|
|
# Ela e gerada em MEMORIA pela etapa de selagem, selada e zerada na mesma
|
|
# linha — em claro ela nunca encosta em disco nosso. Depois que o Argo aplica
|
|
# o SealedSecret, o Secret aberto e o unico lugar de onde da para le-la, e a
|
|
# etapa BANCO_CRIADO precisa dela para dar a senha ao papel.
|
|
#
|
|
# `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.
|
|
# 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.
|
|
#
|
|
# Role, e nao ClusterRole: este Secret vive so aqui. E `resourceNames` de novo,
|
|
# porque `plataforma-prod` guarda a chave do Asaas, o token do webhook e a
|
|
# credencial do Gitea — nenhuma delas tem nada a ver com criar banco de cliente.
|
|
apiVersion: rbac.authorization.k8s.io/v1
|
|
kind: Role
|
|
metadata:
|
|
name: atm-provisionamento-userlist
|
|
namespace: plataforma-prod
|
|
rules:
|
|
- apiGroups: [""]
|
|
resources: ["secrets"]
|
|
verbs: ["get"]
|
|
resourceNames: ["pgbouncer-userlist"]
|
|
# Para saber se o Argo JA aplicou a linha do tenant novo. Sem esta leitura, a
|
|
# etapa reiniciaria o pool as cegas — e reiniciar antes de o Argo aplicar sobe
|
|
# o pod novo lendo a configuracao VELHA, derrubando as conexoes de todos os
|
|
# tenants por nada.
|
|
- apiGroups: [""]
|
|
resources: ["configmaps"]
|
|
verbs: ["get"]
|
|
resourceNames: ["pgbouncer-conf"]
|
|
# O PgBouncer NAO rele a configuracao sozinho: o ConfigMap muda, o kubelet
|
|
# atualiza o arquivo montado, e o processo segue com o que leu na subida. Sem
|
|
# este `patch` o tenant novo fica com banco e papel criados e sem pool, para
|
|
# sempre e sem erro que aponte para ca.
|
|
#
|
|
# `resourceNames` amarra ao pgbouncer: nenhum outro Deployment e alcancavel.
|
|
- apiGroups: ["apps"]
|
|
resources: ["deployments"]
|
|
verbs: ["patch"]
|
|
resourceNames: ["pgbouncer"]
|
|
---
|
|
apiVersion: rbac.authorization.k8s.io/v1
|
|
kind: RoleBinding
|
|
metadata:
|
|
name: atm-provisionamento-userlist
|
|
namespace: plataforma-prod
|
|
subjects:
|
|
- kind: ServiceAccount
|
|
name: atm-provisionamento
|
|
namespace: plataforma-prod
|
|
roleRef:
|
|
apiGroup: rbac.authorization.k8s.io
|
|
kind: Role
|
|
name: atm-provisionamento-userlist
|