Modelo de acesso do vStack Center

Problema e finalidade

Um único cluster atende a muitos usuários: o administrador da plataforma, o administrador de um VDC (data center virtual) individual, um usuário que trabalha apenas com as suas próprias máquinas e um observador que precisa apenas de acesso de leitura e de relatórios. Todos eles usam o mesmo endpoint HTTPS do cluster e chamam os mesmos métodos. Um único indicador "administrador / não administrador" não consegue distingui-los: "visualizar uma rede" e "editar a sua própria rede" são permissões diferentes, e a segunda também se aplica a um conjunto limitado de objetos.

Isso exige um modelo com três camadas, em vez de uma única lista de papéis. Um papel é composto por privilégios, um privilégio lista os métodos aos quais ele dá acesso, e um atributo de escopo limita o privilégio a objetos específicos. Sem uma compreensão clara dessas três camadas, o comportamento da plataforma pode parecer inconsistente: um usuário com papel de administrador em um VDC tem o acesso negado em outro, e um método disponível para "todos os usuários autorizados" retorna conjuntos de campos diferentes para papéis diferentes.

Esta página explica o modelo. Para a criação e a manutenção de contas, consulte Como gerenciar usuários; para criar e atribuir um papel personalizado, consulte Como configurar papéis e privilégios; para sessões e a política de login, consulte Como configurar o login e gerenciar sessões.

Modelo e entidades

O acesso no vStack Center é construído a partir de quatro entidades.

Usuário. Uma conta do cluster com um id numérico, um name, um nome completo fullname e os carimbos de data/hora created e modified. Uma conta não tem senha quando é criada; a senha é definida em uma chamada separada. Os contadores de login são armazenados junto com o perfil: failed_login_attempts, first_failed_at e locked_until. Os identificadores id < 10 são reservados para contas integradas: a plataforma proíbe excluí-las ou alterar as suas atribuições de papéis.

Privilégio. Uma unidade de permissão. Um privilégio tem um id, um name legível, uma categoria category_id, um conjunto de scope_ids e o seu campo principal, methods: uma lista de nomes de métodos JSON-RPC aos quais o privilégio dá acesso. É o privilégio, e não o número do papel, que determina quem pode chamar um método.

Atributo de escopo. Um atributo que limita uma permissão a um subconjunto de objetos. Ele tem um id, um name e um indicador self_referencing. Há dois tipos de atributos, com uma diferença fundamental entre eles:

Atributo	self_referencing	Origem do valor	O que limita
vdc_id	false	a tabela de atribuições user_role_scope	a lista de VDCs em que o papel se aplica
creator	true	gerado a partir do user_id de quem faz a chamada	os objetos criados por quem faz a chamada

Papel. Um conjunto nomeado de privilégios mais um conjunto de atributos de escopo. Os papéis são classificados como fixos ou personalizados com base na faixa do seu identificador.

ID	Nome do papel	Tipo	Nível
1	Cluster Master	fixo	cluster
2	vDC Admin	fixo	VDC
3	vDC User	fixo	VDC
4	vDC Viewer	fixo	VDC
5	Resource Viewer	fixo	cluster
6	Security Admin	fixo	cluster
7	VM Developer	fixo	VDC
≥ 10000	nome personalizado, até 64 caracteres	personalizado	determinado pelos atributos de escopo

Os papéis Security Admin e VM Developer foram introduzidos na versão 3.0.3. O primeiro opera no nível do cluster e dá acesso ao log de segurança e à auditoria; o segundo opera dentro de um VDC e foi projetado para a criação e a configuração de máquinas virtuais.

Os papéis fixos têm o campo creator vazio (null) e não podem ser modificados nem excluídos. Em um papel personalizado, creator armazena o id do usuário que o criou. O papel Cluster master não tem vínculo de escopo: o seu scope_ids é um array vazio, então ele se aplica ao cluster inteiro.

A quinta entidade é uma relação, e não um objeto: uma atribuição. Um papel é atribuído a um usuário junto com um valor de atributo de escopo, dentro de um VDC específico, e não sem escopo. Um mesmo usuário pode ter o papel vDC admin em um VDC e vDC viewer em outro.

Como funcionam as verificações de acesso

Cada requisição passa por quatro verificações em sequência.

1. Sessão. O cluster valida o token de sessão e o substitui por um identificador numérico de usuário; a partir daí, o usuário é identificado dentro do cluster por esse identificador. Uma requisição sem token é rejeitada com o código -9494 ("No session token") antes que qualquer lógica do método seja executada.
2. Papéis de quem faz a chamada. O identificador é usado para montar um mapa de atribuições: quais papéis o usuário tem em quais VDCs. Os usuários podem visualizar o seu próprio mapa; cada atribuição inclui o VDC, o papel, o nome do papel e um indicador de conta GI.
3. Privilégio. O método é verificado em relação às listas methods dos privilégios concedidos pelos papéis do usuário. Se o privilégio estiver ausente, o acesso é negado. O número do papel é irrelevante aqui: um papel importa apenas como um conjunto de privilégios.
4. Escopo. Se um privilégio tiver scope_ids, a permissão se aplica apenas aos objetos dentro desse escopo. Os valores de vdc_id vêm das atribuições de papéis; os valores de creator vêm do uid de quem faz a chamada. Um scope_ids vazio significa um privilégio global.

A diferença entre uma permissão global e uma com escopo é visível na própria atribuição: cada par de papel e atributo de escopo lista valores de atributo ou tem um indicador "sem restrição". Esse indicador significa que as atribuições não contêm valores e que o papel não é restringido por esse atributo. Por exemplo, o papel vDC admin pode ter o seu atributo vdc_id restrito a dois VDCs, enquanto o papel Resource viewer não tem nenhum atributo de escopo.

Os privilégios são agrupados em categorias. Uma categoria apenas agrupa privilégios; ela não afeta as verificações de permissão. O conjunto de categorias é pré-carregado no banco de dados do cluster e cresce à medida que a plataforma adiciona domínios. As dez primeiras são vDC, VM, Network, Edge, Storage, Node, Cluster, User, Misc e Auth; a elas foram adicionadas Security, User Interface, Unified Storage, OS Image Library e Backup.

observação

O exemplo da documentação da API lista apenas as dez primeiras categorias, enquanto o banco de dados contém quinze. A discrepância está no exemplo, e não no comportamento da plataforma: a referência completa de categorias é retornada, então use o conjunto real de categorias do seu cluster.

Dois exemplos do registro de privilégios mostram os dois tipos de restrição:

Privilégio	Categoria	Escopo	Dá acesso ao método
1000 View vDC	1 (vDC)	[1] — vdc_id	vdc-list
2010 Edit Own Network	3 (Network)	[2] — creator	net-set

O primeiro se aplica nos VDCs em que o papel está atribuído. O segundo se aplica apenas às redes criadas por quem faz a chamada, independentemente do VDC.

Limites do modelo

O modelo de privilégios não abrange o próprio gerenciamento de usuários. Muitos métodos do grupo user-* exigem um papel global e retornam o código -403 com a mensagem "Access denied" a todos os demais. Isso se aplica a user-list, user-get, user-create, user-delete, user-unlock, user-role-assign, user-role-deassign, user-roles-map e aos métodos de restrição user-remote-* e user-vhost-*. As permissões de administrador do cluster não podem ser concedidas parcialmente; esse é um conjunto de permissões deliberadamente fechado.

O mesmo princípio impõe quatro restrições que impedem a criação de um papel personalizado "quase Cluster master":

Restrição	Motivo	O que fazer em vez disso
Os privilégios de gerenciamento de papéis 7111–7113 não podem ser atribuídos a um papel personalizado	Caso contrário, o papel poderia ampliar as suas próprias permissões	Deixe o gerenciamento de papéis com o Cluster master
Um atributo autorreferente (creator) é proibido no scope_ids de um papel personalizado	O seu valor é gerado a partir de user_id, então não há valor para vincular ao papel	Use vdc_id e, para a restrição "apenas objetos próprios", use os privilégios Own existentes
Os papéis fixos (id < 10000) não podem ser modificados nem excluídos	Eles definem os contratos centrais da plataforma	Crie um papel personalizado com o conjunto necessário de privilégios
As contas com id < 10 não podem ter as suas atribuições de papéis alteradas nem ser excluídas	As contas integradas mantêm o cluster operacional	Crie um usuário separado

Outro comportamento que pode surpreender à primeira vista: a mesma operação pode retornar quantidades diferentes de dados para papéis diferentes. Qualquer usuário autorizado pode ler as configurações de segurança do cluster, mas, enquanto todos podem ver os requisitos de senha, apenas o Cluster master pode ver o limite de tentativas malsucedidas e a duração do bloqueio.

Onde encontrar isso na interface

As contas e os papéis ficam na mesma seção. Caminho: Provider Data Center → Users & Roles. A seção tem duas abas: Users, uma tabela de contas com as colunas Name, Status, Full Name, Created e Changed; e Roles, uma tabela de papéis com as colunas Name, scope, Creator, Created e Modified. A coluna scope da tabela de papéis é o conjunto de atributos de escopo do papel.

Um papel é aberto em uma tela separada (a barra de endereços mostra #/panel/allusers/roles/). Lá, os privilégios são agrupados em seções: vDC, VM, Network, Edge, Storage, Node, Cluster, User, Misc, Auth, Security e User Interface. Na tela de um papel fixo, os botões Actions, Reset e Save changes ficam desativados, refletindo a proibição de modificar papéis fixos.

Veja também

• Criação de contas, senhas, desbloqueio e restrições de rede — Como gerenciar usuários.
• Criação de um papel personalizado e atribuição de um papel em um VDC — Como configurar papéis e privilégios.
• Sessões, política de senhas e bloqueio de contas — Como configurar o login e gerenciar sessões.
• Conjuntos exatos de campos e a lista completa de códigos de erro — Campos e códigos de erro dos métodos de acesso.

Métodos da API

Operações de API abordadas nesta página: privilege-categories, privilege-list, privilege-scopes, role-list, role-get, role-privilege-list, user-role, user-roles, user-roles-v2, user-roles-map, auth-security-settings-get — consulte a referência da API.