# ============================================================================= # P5.6/P5.9 — a plataforma pode esperar rollout e suspender ESTE tenant. # # O ClusterRole (`atm-provisionamento-tenants`, em # `tenants/plataforma/16-rbac-provisionamento.yaml`) e so a lista de verbos; # quem concede e este RoleBinding, e ele vale SO neste namespace. Um tenant sem # este arquivo simplesmente nao e alcancado pelo provisionamento — a etapa falha # com 403 dizendo o caminho que tentou, que e melhor do que um acesso amplo. # ============================================================================= apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: atm-provisionamento namespace: teste5-prod subjects: - kind: ServiceAccount name: atm-provisionamento namespace: plataforma-prod 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 # teste5-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: teste5-prod rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get"] resourceNames: ["db-credentials", "kc-admin-secret", "teste5-tls"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: atm-provisionamento-segredos namespace: teste5-prod subjects: - kind: ServiceAccount name: atm-provisionamento namespace: plataforma-prod roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: atm-provisionamento-segredos