All Windows processes are started and owned by a user account. The permissions of the user account determine whether the process can access files and other resources and whether they are available to modify or just to view. In the Docker base image for Windows Server Core, there is a default user account called container administrator. Any process you start in a container from that image will use that user account—you can run the whoami tool, which just writes out the current username:
> docker container run mcr.microsoft.com/windows/servercore:ltsc2019 whoami
user managercontaineradministrator
You can run an interactive container by starting a PowerShell and find the user ID (SID) of the container administrator account:
> docker container run -it --rm mcr.microsoft.com/windows/servercore:ltsc2019 powershell
> $user = New-Object System.Security.Principal.NTAccount("containeradministrator"); `
$sid = $user.Translate([System.Security.Principal.SecurityIdentifier]); `
$sid.Value
S-1-5-93-2-1
You'll find that the container user always has the same SID, S-1-5-93-2-1, as the account is part of the Windows image. Due to this, it has the same attributes in every container. The container process is really running on the host, but there is no container administrator user on the host. In fact, if you look at the container process on the host, you'll see a blank entry for the username. I'll start a long-running ping process in a background container and check the process ID (PID) inside the container:
> docker container run -d --name pinger mcr.microsoft.com/windows/servercore:ltsc2019 ping -t localhost
f8060e0f95ba0f56224f1777973e9a66fc2ccb1b1ba5073ba1918b854491ee5b
> docker container exec pinger powershell Get-Process ping -IncludeUserName
Handles WS(K) CPU(s) Id UserName ProcessName
------- ----- ------ -- -------- -----------
86 3632 0.02 7704 User ManagerContai... PING
This is a Windows Server container running in Docker on Windows Server 2019, so the ping process is running directly on the host, and the PID inside the container will match the PID on the host. On the server, I can check the details of that same PID, which is 7704 in this case:
> Get-Process -Id 7704 -IncludeUserName
Handles WS(K) CPU(s) Id UserName ProcessName
------- ----- ------ -- -------- -----------
86 3624 0.03 7704 PING
There is no username because the container user does not map any users on the host. Effectively, the host process is running under an anonymous user, and it has no permissions on the host, it only has the permissions configured within the sandboxed environment of one container. If a Windows Server vulnerability was found that allowed attackers to break out of a container, they would be running a host process with no access to host resources.
It's possible that a more extreme vulnerability could allow the anonymous user on the host to assume wider privileges, but that would be a major security hole in the core Windows permissions stack, one of the scale that typically gets a very fast response from Microsoft. The anonymous host user approach is a good mitigation to limit the impact of any unknown vulnerabilities.