Putting JEA to good use on Hyper-V clusters - Evgenij Smirnov - PSConfEU 2023

We will start by looking at JEA and its capabilities in regard to Hyper-V management at different levels. I clarify that we will not be covering AI, PowerShell 7, or Windows Terminal in this session. I reference the official NIST publication which emphasizes the need for segregation of duty when delegating control of virtual machines to specific users or groups. Our objective is to delegate management tasks to application administrators for their respective VMs. We will only be focusing on delegation of VM management and not host or storage management.

I discuss the different tools available for Hyper-V management, such as Hyper-V Manager, Failover Cluster Manager, PowerShell modules, and Windows Admin Center. I highlight that the problem with these tools is that delegation is practically non-existent. The Hyper-V RBAC system is deprecated and the Hyper-V administrators group grants too much access.

So, we're discussing different solutions for software architectures for delegations. There are two approaches we can take. The first approach is to have an agent on each host that communicates with a back-end. The agent runs in the system context and performs the RBAC (role-based access control) tasks. An example of this is the system center virtual machine manager. The other approach is to provide your own management experience and use a God-level account to perform allowed actions remotely. An example of this is Hyper-V Manager, but it's not recommended due to security issues.

Since we're at the PowerShell conference and talking about delegation, we bring up GIA (JEA). GIA works by allowing users to connect to a specific endpoint using WinRM transport. The registered endpoint determines what modules and cmdlets the users can access and what parameters and values they can use. The command itself is run using a highly privileged account, which can be a virtual account tied to the user identity or an explicitly specified account. GIA offers granularity in terms of VMs and actions allowed, but it may not be very convenient to use.

There's another approach, where we don't rely on the built-in GIA logic, but instead provide our own permissions topology and map the user identity connecting to the endpoint. This requires a data store, such as SQLite or a CSV table. The psSenderInfo object can be used to obtain the Windows identity of the connecting user, including the SID and group memberships.

For a demonstration, we have a host with multiple VMs belonging to different users. We have set up a simple GIA endpoint on the Hyper-V host with a global access group. Users in this group are assigned a JIA role, and a role capability stored in a module maps SIDs to machine names and determines their permissions (start or stop).

In summary, there are different approaches to software architectures for delegations, such as using agents on each host or utilizing GIA. Each approach has its pros and cons, and it's important to consider security and convenience when designing a solution.

We have a command function called updateMyVMList that does nothing fancy. It imports the default Hyper-V module, reads the authorization table, and populates three global lists: myVM get list, myVM start list, and myVM stop list. These lists contain the VMs that the user is allowed to access. When the "get myVM" command is invoked, it returns the VMs that the user is authorized to see. The function also includes a virtual identity feature that shows the real identity within the virtual identity name. This approach allows for role-based access control and can be used with e…