In a Windows Server Core container, the default user account is the container administrator. This account is in the administrator group on the container, so it has complete access to the whole filesystem and all the resources on the container. The process specified in the CMD or ENTRYPOINT instruction in a Dockerfile will run under the container administrator account.

This can be problematic if there is a vulnerability in the application. The app could be compromised, and, while the chances of an attacker breaking out of the container are small, the attacker could still do a lot of damage inside the application container. Administrative access means that the attacker could download malicious software from the internet and run it in the container or copy state from the container to an external location.

You can mitigate this by running container processes under a least-privilege user account. The Nano Server images use this approach—they are set up with a container administrator user, but the default account for container processes is a user without admin permissions. You can see that, by echoing the username in a Nano Server container:

> docker container run mcr.microsoft.com/windows/nanoserver:1809 cmd /C echo %USERDOMAIN%\%USERNAME%
User ManagerContainerUser

The ContainerUser account does not have admin access inside the container. If you need admin rights to set up your application, you can switch to the admin account in your Dockerfile with the USER ContainerAdministrator command. But if your application doesn't need admin access, you should switch back at the end of your Dockerfile with USER ContainerUser so that the container startup command runs as the least-privilege account.

The Internet Information Services (IIS) and ASP.NET images from Microsoft are other examples of running as least-privilege users. The external-facing process is the IIS Windows service, which runs under a local account in the IIS_IUSRS group. This group has read access to the IIS root path C:inetpubwwwroot, but no write access. An attacker could compromise the web application, but they would not be able to write files, so the ability to download malicious software is gone.

In some cases, the web application needs write access to save the state, but it can be granted at a very fine level in the Dockerfile. As an example, the open source content management system (CMS) Umbraco can be packaged as a Docker image, but the IIS user group needs write permissions to the content folder. Rather than changing the Dockerfile to run the service as an administrative account, you can set ACL permissions with a RUN instruction:

RUN $acl = Get-Acl $env:UMBRACO_ROOT; `
    $newOwner = [System.Security.Principal.NTAccount]('BUILTINIIS_IUSRS'); `
    $acl.SetOwner($newOwner); `
    Set-Acl -Path $env:UMBRACO_ROOT -AclObject $acl; `
    Get-ChildItem -Path $env:UMBRACO_ROOT -Recurse | Set-Acl -AclObject $acl

You should use a least-privilege user account to run processes and set ACLs as narrowly as possible. This limits the scope for any attackers who gain access to the process inside the container, but there are still attack vectors from outside the container that you need to consider.