Usuários, papéis e permissões no Proxmox: quem pode o quê

A instalação padrão do Proxmox tem um usuário: root@pam. E é assim que muitos ambientes seguem para sempre — todo mundo com a senha de root, todo mundo podendo tudo. Funciona até o dia em que alguém apaga a VM errada, e a pergunta "quem fez isso?" não tem resposta possível.

O modelo de permissões do Proxmox é mais capaz do que a maioria das pessoas descobre. Ele tem cinco conceitos, e entendê-los na ordem certa resolve o assunto em uma tarde.

Os cinco conceitos, na ordem que importa

Realm — de onde vem a autenticação. pam é o usuário do sistema Linux; pve é o usuário interno do Proxmox; e há realms para LDAP, Active Directory e OpenID.
Usuário e grupo — quem é. Permissão se atribui a grupo, quase nunca a usuário.
Papel (role) — um conjunto nomeado de privilégios. PVEVMAdmin, PVEAuditor, PVEDatastoreUser e outros já vêm prontos, e você pode criar os seus.
Caminho (path) — onde a permissão vale. /vms/101, /pool/marketing, /storage/ceph, /nodes/pve01, ou / para tudo.
Pool — um agrupamento lógico de VMs e storages, que existe justamente para ser um caminho de permissão.

A regra que amarra tudo: uma permissão é a associação de um grupo a um papel em um caminho. E ela é herdada para baixo — permissão em /pool/marketing vale para todos os recursos que estão naquele pool.

Comece pelos realms

O realm pve cria usuários que só existem dentro do Proxmox. É o certo para contas de operação e de automação, porque não dá acesso ao sistema operacional do host.

O realm pam são usuários Linux do nó. Reserve para o root e para casos em que alguém precisa mesmo de shell no hipervisor — que deveriam ser poucos.

Para empresas com diretório corporativo, o realm de LDAP ou Active Directory é o caminho: as contas nascem e morrem no diretório, e o desligamento de um funcionário revoga o acesso ao hipervisor sem ninguém precisar lembrar. Isso merece artigo próprio, mas fica a indicação de direção.

A regra imediata, independente de realm: habilite autenticação de dois fatores para qualquer conta com privilégio administrativo. O Proxmox suporta TOTP e chaves de hardware, e a configuração leva minutos.

Os papéis prontos, e o que cada um serve

Papel	O que permite	Bom para
`Administrator`	Tudo	Ninguém, em caminho `/` — use com moderação
`PVEAdmin`	Quase tudo, exceto alterar permissões	Administrador de plataforma
`PVEVMAdmin`	Ciclo de vida completo de VM	Time de aplicação sobre suas próprias VMs
`PVEVMUser`	Ligar, desligar, console, sem criar nem apagar	Usuário final de VM
`PVEDatastoreUser`	Alocar espaço e ver conteúdo próprio	Quem cria VM em um storage específico
`PVEAuditor`	Somente leitura	Auditoria, monitoramento, integração de coleta
`PVEPoolAdmin`	Administrar um pool	Responsável por um conjunto de recursos
`PVESysAdmin`	Configuração de nó, sem acesso a VM	Operação de infraestrutura
`NoAccess`	Nega explicitamente	Exceção pontual dentro de um caminho permitido

O papel mais útil e menos usado é PVEAuditor. Toda ferramenta de monitoramento, todo dashboard e todo script de inventário deveriam usar uma conta com ele — e não com root. É o ganho mais barato de segurança no Proxmox.

Pools: a peça que organiza tudo

Pool é a abstração que torna o modelo administrável. Sem pools, você atribui permissão VM a VM, e em seis meses ninguém sabe mais quem pode o quê.

Com pools, você cria agrupamentos que refletem a realidade — por cliente, por área, por ambiente — e atribui a permissão ao pool inteiro. VM nova adicionada ao pool herda automaticamente quem pode mexer nela.

Desenhos que funcionam bem:

Provedor de cloud: um pool por cliente. O grupo do cliente recebe PVEVMUser no pool dele. Ele liga, desliga e acessa o console das suas VMs, e não enxerga as dos outros.
Empresa com vários times: um pool por time. O time recebe PVEVMAdmin no pool e cria as próprias VMs dentro do storage alocado.
Separação de ambiente: pools de produção, homologação e desenvolvimento. Desenvolvimento com permissão ampla, produção restrita a poucos.

Um detalhe que pega: criar VM exige também permissão no storage onde o disco vai morar, e no nó. Dar PVEVMAdmin no pool e esquecer o storage gera o clássico "não consigo criar VM e não entendo por quê".

Tokens de API: a peça que quase ninguém configura direito

Automação não deve usar senha de usuário. O Proxmox tem tokens de API, que são credenciais separadas, vinculadas a um usuário, com duas características importantes:

Privilégio separável. Um token pode ter permissões menores que o usuário dono dele. Marque a opção que separa os privilégios e atribua ao token exatamente o que o script precisa.
Revogáveis individualmente. Vazou o token do script de backup? Revoga aquele token e o resto do ambiente continua funcionando.

O padrão que recomendamos: um usuário de serviço no realm pve por integração, com um token para cada, com privilégio separado e escopo mínimo. O token do monitoramento tem PVEAuditor em /. O token do Terraform tem o necessário para criar VM no pool e no storage que ele gerencia, e nada além.

O desenho de acesso mínimo, na prática

Um roteiro que funciona na maioria dos ambientes:

Root com senha forte, 2FA e uso excepcional. Não é a conta do dia a dia de ninguém.
Um usuário nominal por pessoa, no realm apropriado, com 2FA em quem tem privilégio.
Grupos por função, não por pessoa: infra, suporte-n1, desenvolvimento, auditoria.
Pools por cliente, time ou ambiente.
Permissões atribuídas a grupo, em pool, com o papel mais restrito que resolve o trabalho.
Tokens de API por integração, com privilégio separado e escopo mínimo.
Revisão periódica de quem tem o quê. Trimestral já é suficiente e já revela surpresas.

O suporte N1 é o melhor teste do modelo

Um caso concreto que mostra o modelo funcionando: o atendimento de primeiro nível precisa reiniciar VM de cliente e ver o console para diagnosticar. Não precisa — e não deveria — poder apagar VM, mudar hardware virtual ou mexer em storage.

PVEVMUser em /, atribuído ao grupo do N1, entrega exatamente isso. A pessoa resolve o chamado, e o pior erro possível dela é reiniciar a VM errada — o que é recuperável, ao contrário de apagá-la.

Se o seu N1 opera com root porque "é mais fácil", esse é o primeiro item a corrigir.

Auditoria: permissão sem registro é metade do trabalho

O Proxmox registra as tarefas com o usuário que as executou. Isso só tem valor se os usuários forem nominais — com todo mundo usando root, o log diz root@pam e não diz nada.

Vale exportar esses registros para o seu sistema de log centralizado, para que fiquem fora do nó e sobrevivam a um incidente. E vale saber responder, antes que alguém pergunte: quem desligou aquela VM, e quando.

Erros comuns

Toda a equipe usando root@pam com a mesma senha.
Nenhum 2FA em conta administrativa.
Permissão atribuída a usuário individual em vez de grupo.
Permissão atribuída VM a VM, sem pools.
Dar permissão no pool e esquecer o storage e o nó — criação de VM falha sem motivo aparente.
Ferramenta de monitoramento usando root em vez de PVEAuditor.
Script de automação usando senha de usuário em vez de token de API.
Token de API sem privilégio separado, herdando tudo do usuário.
Papel Administrator em / distribuído por conveniência.
Nenhuma revisão periódica de acesso — gente que saiu da empresa ainda entra.
Log de tarefas só no nó, perdido junto com o nó em um incidente.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, desenhamos e implantamos esse modelo: integração com o diretório corporativo quando existe, grupos por função, pools que refletem a sua organização, papéis com privilégio mínimo, 2FA nas contas administrativas, tokens de API com escopo por integração e exportação dos registros de auditoria. E deixamos documentado quem pode o quê — porque controle de acesso que ninguém entende é revertido no primeiro incidente.

Sabe dizer quem tem acesso ao seu hipervisor hoje? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.