Configuração centralizada de acesso

TLDR: Unificar rbac/owners.yml e rbac/infra.yml num único config.yml que passa a dirigir, de uma só fonte, o RBAC do Kubernetes, os reviewers de ambiente do GitHub e o acesso ao console por projeto.

Contexto

rbac/owners.yml mapeava projeto → e-mail para o RBAC do Kubernetes, e os reviewers de ambiente do GitHub eram configurados à mão em cada repo. Um projeto pode ter vários repos (onion tem onion-backend e onion-mobile), o que agravava a duplicação. Faltava uma fonte de verdade única.

Objetivos

• Um único YAML com identidades, projetos, apps e permissões por usuário.
• O CI lê o config e aplica: RoleBindings no Kubernetes + reviewers de ambiente no GitHub.
• Substituir rbac/owners.yml e rbac/infra.yml pelo formato unificado.
• Nova ClusterRole project-admin-production para o acesso console-admin (criar pod temporário).

Fora de escopo

• Isolamento de acesso ao cluster por projeto (members) — veio na spec seguinte.

Mudanças

rbac/config.yml (novo, substitui owners.yml + infra.yml)

Três permissões por usuário dentro de cada projeto:

Acesso automático, sem entrada no config: todo membro da organização recebe o perfil dev (total em staging, read-only em produção); quem está em infra tem total em tudo, inclusive namespaces de sistema.

```yaml users: porpino: github: oporpino k8s: porpino@wehive.tech

infra: [porpino]

projects: onion: apps: [onion-backend, onion-mobile] permissions: porpino: [deploy, console, console-admin] elinaldo: [deploy, console] ```

src/stacks/shared/kubernetes/rbac/terraform/rbac.tf

• ClusterRole project-admin-production com create/get/list/delete em pods, pods/exec e pods/attach.
• locals.config = yamldecode(file(...)) lendo o config.yml, derivando infra_emails e project_admins (usuários com console-admin, achatados por projeto).
• RoleBinding project_admin por par projeto/usuário, criado só se o namespace <project>--production existir.

CI e commons

• .github/workflows/rbac.yml — passo novo, depois do terraform apply, que sincroniza os reviewers de ambiente.
• .commons/shell/tasks/ci/github/sync-environment-reviewers.sh (novo) — lê o config, resolve username do GitHub → ID via API e cria/atualiza o ambiente production de cada app com esses reviewers.
• .commons/make/shared/infra.mk — targets console.staging.admin e console.production.admin.
• .commons/shell/tasks/infra/k8s/console-admin.sh (novo) — kubectl run console-admin --rm -it com DATABASE_URL completa.

Como verificar

```bash # RBAC aplicado kubectl auth can-i create pods -n onion–production –as=porpino@wehive.tech # yes (console-admin) kubectl auth can-i create pods -n onion–production –as=elinaldo@wehive.tech # no (só console)

ambiente do GitHub atualizado

gh api repos/ibft-corp/onion-backend/environments/production –jq ‘.protection_rules’

console

make console.staging # exec no pod, DATABASE_READONLY_URL make console.staging.admin # pod temporário, DATABASE_URL completa ```

Documentação

• Guia de acesso — how-to para desenvolvedores (criado por esta spec).
• Skill commons:infra — seção de RBAC com o formato novo.

Nota: o arquivo hoje vive em config/access.yml, movido pela reestruturação da infraestrutura, e o modelo de permissão evoluiu para members/owners por projeto mais um bloco devops.