Como o acesso funciona
Toda decisão de acesso na plataforma responde a duas perguntas separadas: qual ação está sendo executada e onde ela vale. Quem pode reiniciar uma máquina virtual em um VDC não ganha automaticamente o direito de reiniciar outra em um VDC diferente. A ação e o lugar são concedidos juntos, e os dois precisam bater.
Entender esses dois eixos já basta para raciocinar sobre quase tudo na tela de IAM.
Os dois eixos
- Permissão — a ação em si, escrita como uma chave, por exemplo
vm:poweroubackup:restore. Ela diz o que pode ser feito, nunca sobre qual recurso. - Escopo — a parte do seu tenant em que a permissão vale. Ele diz onde.
Como o recurso vive no escopo e não na chave, não existe uma permissão do tipo "ver a VM 42". Deixar alguém enxergar as VMs de um único VDC é a permissão vm:view concedida no escopo daquele VDC.
Hierarquia de escopos
Os escopos são aninhados, do mais amplo ao mais restrito:
PLATFORM › TENANT › CUSTOMER › VDC
Uma permissão concedida em um nível vale para os níveis abaixo dele, com uma exceção importante descrita logo em seguida.
| Escopo | O que abrange | Precisa de alvo |
|---|---|---|
| Plataforma | Toda a plataforma, em todos os tenants. Reservado à equipe EdgeX. | Não |
| Tenant | A administração do próprio tenant: pessoas, grupos, customers, faturamento. | Não |
| Customer | Um customer e todos os VDCs que pertencem a ele. | Sim |
| VDC | Um virtual datacenter. | Sim |
Plataforma e tenant abrangem uma fronteira inteira, então não precisam de alvo. Customer e VDC valem para um objeto específico, então você escolhe qual no momento da concessão.
Para agir sobre um recurso que vive dentro de um VDC — uma VM, um disco, uma regra de firewall, um backup — a permissão precisa ser concedida naquele VDC ou no customer dono dele. Conceder no escopo de tenant não basta, mesmo o tenant estando mais acima na hierarquia.
O escopo de tenant serve para administrar o tenant. Quem também precisa operar infraestrutura precisa de uma segunda atribuição, no customer ou no VDC.
Grupos e concessões diretas
Existem duas formas de um usuário acabar com uma permissão.
| Grupo | Concessão direta | |
|---|---|---|
| O que é | Um conjunto nomeado de permissões atribuído a um usuário em um escopo | Uma única permissão dada a um usuário em um escopo |
| Use para | Acesso do dia a dia, qualquer coisa que mais de uma pessoa precise | Exceções e acesso temporário |
| Expira | Opcional | Sempre — a data de expiração é obrigatória |
| Como revogar | Remover a atribuição | Revogar a concessão |
Grupos são o caminho normal. Um grupo reúne as permissões de uma função — "operar o VDC", "gerenciar customers" — e você atribui esse grupo a um usuário em um escopo. O mesmo grupo pode ser atribuído a pessoas diferentes em VDCs diferentes, e é isso que mantém a lista de permissões administrável conforme o time cresce.
Concessões diretas são a válvula de escape, para quando uma pessoa precisa de uma permissão a mais por um período curto. Elas exigem uma data de expiração futura, de modo que o acesso temporário continue temporário em vez de virar permanente sem ninguém perceber. Se você se pegar dando a mesma concessão direta a várias pessoas, esse é o sinal de que o caso pede um grupo.
Grupos padrão
Todo tenant já vem com dois grupos prontos:
| Grupo | Escopo | Para |
|---|---|---|
CUSTOMER-ADMIN | Customer | Tudo dentro de um customer: operar todos os VDCs dele e gerenciar quem os acessa |
VDC-OPERATOR | VDC | Operar um único VDC — computação, storage, rede, backup — com acesso somente leitura ao IAM |
Os dois carregam as mesmas permissões de infraestrutura. O CUSTOMER-ADMIN as aplica em todos os VDCs do seu customer e ainda soma a gestão completa de IAM, então é o grupo para quem toca um customer no dia a dia.
Um terceiro grupo, PLATFORM-ADMIN, é da equipe EdgeX e não é atribuível dentro do seu tenant.
Você pode criar seus próprios grupos quando nenhum dos dois servir.
Permissões efetivas
As permissões efetivas de um usuário são tudo que ele possui, vindo de todas as atribuições de grupo e de todas as concessões diretas, somado — cada permissão acompanhada do escopo de onde veio.
Permissões apenas se somam. Atribuir um segundo grupo pode ampliar o acesso de alguém, mas nunca reduzi-lo, e não existe regra de negação que retire uma permissão. Para diminuir o que um usuário pode fazer, remova a atribuição ou a concessão que dá aquilo.
A aba Permissions mostra essa visão somada para qualquer usuário, incluindo a origem de cada permissão. É o caminho mais rápido para responder "por que essa pessoa consegue fazer isso?".
Como ler as chaves de permissão
As chaves são escritas como seção:recurso:ação, por exemplo vm:snapshot:rollback. O primeiro segmento é a área do produto e corresponde à seção da barra lateral onde o recurso fica.
Algumas convenções valem a pena conhecer:
- Leitura é ampla. Uma única chave
<seção>:viewcobre listar e ver tudo daquela seção. Leituras sensíveis ficam em chaves próprias, comovm:console:vieweiam:audit:view. - Ações destrutivas têm chave própria, para que
backup:restoreouvm:disk:destroypossam ser negadas a quem, no restante, opera o recurso normalmente. - Uma chave terminada em
:*cobre tudo abaixo dela, em qualquer profundidade.storage:*inclui tantostorage:viewquantostorage:object_storage:bucket:delete. São convenientes, mas também absorvem permissões adicionadas em versões futuras — prefira chaves específicas quando o acesso for sensível.
Quando as mudanças passam a valer
As permissões são lidas no login e renovadas periodicamente enquanto você trabalha, então uma mudança de acesso nem sempre aparece na hora. Ela vale a partir da próxima renovação, em cerca de cinco minutos. Sair e entrar de novo aplica imediatamente.
Se alguém disser que um acesso recém-concedido não está funcionando, normalmente é isso.