Hierarquia testada

1. Clientes
2. Clusters
3. Nós
4. VMs / CTs
5. Modelos
6. Armazenamento
7. Redes

As permissões propagam-se ao longo desta árvore. Em cada nível verifica-se o que cada conta pode ver e o que pode alterar.

Quatro dimensões

• GUI

  Interface real

  O conjunto de testes usa os controlos reais — menus, separadores, botões e menus de contexto — exatamente como cada utilizador, e regista o que é mostrado, ocultado ou desativado.

• API

  Chamadas diretas

  As mesmas operações são enviadas diretamente à API. Usado quando o produto não tem um controlo na interface ou as permissões da conta o ocultam — sempre assinalado no relatório.

• Isolamento

  Verificações de fuga

  Cada leitura — listas, painéis, pesquisas, mapas e topologia — tem de devolver apenas os recursos da própria conta. Qualquer cliente, cluster, nó, VM ou CT alheio conta como fuga.

• Segurança

  Provas de isolamento de escrita

  Ações de gestão — criar, editar, eliminar, ligar/desligar, migrar, clonar — são tentadas fora dos direitos da conta e têm de ser recusadas. Também se testam o rate limiting da API e o bloqueio de conta.

Contas testadas

15 contas cobrem todos os âmbitos de permissão: global (super-admin, admin e só leitura), cliente, cluster, nó e VM/CT individual, cada uma com o papel Admin, Operador ou Visualizador — mais uma conta sem qualquer permissão, que não pode ver nem fazer nada.

Como ler os resultados

• PASSA conta comportou-se exatamente como esperado: permitido onde tem direito, bloqueado onde não tem.
• FAILO resultado difere do que o modelo de permissões exige.
• SKIPA verificação não se aplica a essa conta ou ambiente, pelo que não conta como sucesso nem como falha.
• FUGASA conta acedeu a dados fora da sua atribuição. O objetivo é sempre zero.
• BLOQUEIOS CORRETOSAções proibidas recusadas exatamente como deviam.