Capacidades transversais — visão geral
Capacidades transversais são requisitos horizontais que atravessam todas as camadas. Tratá-las só “dentro” de uma camada gera redundância e inconsistência.
Pra entender como transversais se relacionam com as outras 4 dimensões (camadas, frentes estratégicas, operações, roadmap), ver Apresentação.
Diferença essencial: “política” vs “execução”
| Dimensão | Foco em transversais |
|---|---|
| Capacidades transversais (esta seção) | Política — o que precisa ser garantido (ex: “secrets nunca em git plano”) |
| Operações | Execução — como fazer rotineiramente (ex: “rotação de secrets toda quarta-feira”) |
| Roadmap | Sequência — quando implementar (ex: “secrets management entra Fase 0”) |
As 9 capacidades transversais
| Capacidade | Pra que serve | Doc |
|---|---|---|
| Identidade & Acesso (IAM) | SSO, RBAC, audit por usuário/grupo | /transversais/iam/ |
| Secrets management | Tokens, chaves, certificados privados fora de git plano | /transversais/secrets/ |
| Certificados (TLS) | Rotação automática, terminação TLS em todas exposições | /transversais/certificados/ |
| Observabilidade | Logs, métricas, traces, alertas — fonte única pra diagnóstico | /transversais/observabilidade/ |
| CI/CD de IaC | Validar mudanças em Pulumi, Ansible, manifests antes de aplicar | /transversais/cicd/ |
| Supply chain | Registry, scan de imagens, assinatura, base images padronizadas | /transversais/supply-chain/ |
| Segurança (defesa de borda) | Firewall, IDS/IPS, defense-in-depth | /transversais/seguranca/ |
| Backup e continuidade | DR, restore testado, política de retenção | /transversais/backup-continuidade/ |
| Documentação e governança | ADRs, runbooks, processo de mudança, audit institucional | /transversais/governanca/ |
Por que separar de camadas
Algumas capacidades vivem em camadas específicas mas suas regras precisam ser consistentes em todas:
- TLS é configurado no Traefik (camada 4) mas precisa cobrir comunicação K8s interna (camadas 5-7) e ingress externo (camada 4)
- Audit log é gerado pelo K3s (camada 4) mas armazenado no OpenObserve (camada 7) e consumido por compliance (transversal)
- Secrets afetam configs de Proxmox (camada 0), LINSTOR (camada 1), apps (camada 9) — política única em todas
Tratar capacidades transversais como eixo horizontal evita:
- Repetir explicação em cada camada
- Inconsistência entre camadas (TLS rotação manual em uma, automática em outra)
- “Esquecer” cobertura em alguma camada
Hierarquia de prioridade no MVP
Pelo contexto institucional (FAPESP audit + Lab Multiusuário), algumas capacidades transversais viram MVP, não “futuro”:
| Capacidade | Status pretendido | Justificativa |
|---|---|---|
| Secrets management | 🔥 MVP | Sem isso, qualquer credencial em git é leak |
| Certificados | 🔥 MVP | Sem TLS automático, exposição pública insegura |
| CI/CD de IaC | 🔥 MVP | Sem validação em PR, mudança em prod é roleta |
| IAM granular | 🔥 MVP (Lab Multiusuário) | Múltiplos grupos exigem RBAC formal |
| Audit centralizado | 🔥 MVP (FAPESP) | Prestação de contas exige trilha de auditoria |
| Observabilidade | 🚧 Em construção | OpenObserve setup parcial |
| Cost attribution | 🟡 Antes da plataforma GPU | FAPESP exige relatório por projeto |
| Supply chain | 🟡 Pós-MVP | Quando aparecer caso real |
| Defesa de borda | 🟢 MVP simples (fail2ban+CF) | Avançada (CrowdSec) deferida |
Detalhe das fases: Roadmap.