Controlled access to virtual machines running on Proxmox, VMware and Hyper-V

Secure access to a virtual machine is built in two separate layers. The hypervisor (Proxmox, VMware, Hyper-V) decides who can start and stop a virtual machine and who can see its console. Who enters the operating system inside the machine, for how long and (if the policy requires it) with what approval is the job of the second layer. Cerberus governs that second layer: it assigns a person (or an AI worker) to the resource, limits the time, asks for approval when the policy requires it, revokes access and keeps the records.

Cerberus does not host or create virtual machines and does not manage hypervisor consoles. A virtual machine connects to Cerberus like any other server or desktop.

Why is virtual machine access two layers?

A hypervisor permission and a login to the machine answer different questions:

Someone with console permission sees the machine’s screen and can sign in if they have an operating system account; someone without console permission may still reach the machine over the network with RDP or SSH. The two permissions do not replace each other. Keeping the number of hypervisor administrators small does not solve access inside the machines.

How does Cerberus reach a virtual machine?

Cerberus manages a virtual machine through the same paths as any other resource, not through the hypervisor. It does not connect to a hypervisor API or management console. There are two paths:

• Windows virtual machine: a Windows Agent is installed on the machine. The Agent produces registration, service health and RDP readiness signals. See Windows Agent for setup and scope.
• Linux, or a machine where the Agent cannot be installed: the resource connects as an RDP, SSH or VNC target through a private network gateway or a manual resource definition. These models are described in connecting resources without an Agent.

For step-by-step connection use the connecting a machine guide. Whether the connected resource is ready is read from the signals on resource readiness and agent trust. For resources connected without an Agent, in-machine health signals are limited.

Access authorization for virtual machines on Proxmox

On Proxmox, virtual machine permissions are managed through Proxmox’s own role and permission model; details vary by setup.

Cerberus does not replace this permission model. For people who will work inside a Linux or Windows machine running on Proxmox, Cerberus makes a separate decision: the person is assigned to the resource, a duration is set, the session is approved when the policy requires it and the outcome is recorded at closure. A person who is not a Proxmox administrator can work on the machine they are assigned to; a person with Proxmox console permission cannot open a Cerberus session on a machine they are not assigned to.

Access control for virtual machines on VMware

In VMware environments, virtual machine and console permissions are managed through VMware’s own role and permission model; details vary by setup.

In Cerberus, a machine running on VMware is a resource for assignment and session decisions. What someone can do in vCenter is not carried over to Cerberus; Cerberus governs who can open an RDP, SSH or VNC session inside the machine, for how long and under which policy. Assigning the resource is covered in the assigning resources guide.

Connection authorization for virtual machines on Hyper-V

In Hyper-V, authorization for console connections (VMConnect) depends on Hyper-V’s own administration and authorization structure; details vary by setup.

In Cerberus, a Hyper-V virtual machine is managed like a Windows machine with the Windows Agent installed, or as an RDP target behind a gateway. VMConnect console access and a Cerberus session are separate permissions: console connection stays in hypervisor administration, and work inside the machine depends on the Cerberus assignment and session policy.

What does Cerberus add to virtual machine access?

Hypervisor permissions govern the virtual machine’s lifecycle. Cerberus adds these controls to access inside the machine:

• Assignment. A person works only on the assigned machine; they do not get a path into the whole network or the hypervisor environment.
• Time limit. Access is limited by an end time or a usage budget. The full approach is on the time-limited (JIT) access page.
• Approval. When the active session policy requires it, a session request goes to an authorized user; approval sets the permitted duration, rejection opens no session.
• Revocation. The assignment is removed and the open session is ended; each operation’s outcome is shown separately.
• Records. Decision, start, state change, revocation and closure events stay in the audit record. These are event records; they do not include session video.

In the normal flow, users are not given a raw IP, hostname or port. The session opens in the browser through a Cerberus decision.

How is access set up for a virtual machine?

The hypervisor type does not change the flow; the machine’s operating system and protocol decide.

The flow has five steps:

1. The virtual machine is connected as a resource through one of the paths above.
2. The resource is checked for readiness.
3. The person is assigned to the resource and a duration is set if needed.
4. If the policy requires it, the session request is approved; the person opens the session in the browser.
5. When the work ends, the assignment is removed or the time runs out; an open session is ended separately.

What does Cerberus not do?

• It does not host or create virtual machines.
• It does not connect to the Proxmox, VMware or Hyper-V management interface or API, and it does not read or change hypervisor permissions.
• It does not offer the hypervisor console through another interface.
• It does not close a machine’s network exposure on its own. For a manually defined target, open ports and firewall state remain with the deployment owner.

How are the hypervisor and Cerberus used together?

In practice the two permission sets run side by side. Virtual machine management in the hypervisor is left to a small administrator group. People who work inside the machines get resource-level, time-limited assignments in Cerberus, with approval where the policy requires it. When a job ends, access is closed by removing the assignment or letting the time run out, not by editing hypervisor roles.

For examples see use cases, and for the credential side see credential custody. To try it with your own virtual machines, open the get started page.