Containers in general are seen as a turnkey solution to run applications. Once the app has been finalized, you expect the container to run the same way regardless of the environment. However, just like any other platform, there are some important aspects that need to change between development and production – especially when it comes to identity and security.
By default, Windows containers run with a user account called ContainerAdmintrator which has admin access inside the container instance. If compromised, this container instance will allow an attacker to take control over shared resources – such as, but not limited to, mounted volumes. For that reason, whenever running on multi-tenant or least privileged environments we recommend to use the ContainerUser profile.
When to use ContainerUser and ContainerAdministrator
As mentioned, the ContainerAdministrator profile has full admin privileges on the container instance. This is a great fit for administrative and IT tasks which is why this is the default user profile when using Windows containers. If you’re configuring your container image, installing pre-requisite software, or your application you’ll need admin permissions for that. However, after that process is completed, you could move to a different user profile with no admin privileges. For example, a container instance running a web application doesn’t need to run with administrative rights if the application is already deployed. For that, you have the ContainerAdministrator.
The thing to notice here is that regardless of the profile of the container instance, you can still configure outside access for the container with other profiles. For example: If you have a web application that requires the user using the application to authenticate with gMSA, you can still run the container instance using the ContainerUser profile. The Active Directory authentication will happen outside of the OS instance inside the container.
Changing the user profile for Windows containers
Changing the user profile is actually really simple – It’s a simple line on your Docker file. For example, if I want my container instance to run as ContainerUser:
USER ContainerUser
The trick here is to ensure the line is placed at the right moment. For example, if your dockerfile describes how to install an application, you should add the USER line after the installation process is completed. Remember, each line on a Docker file represents a new layer on your container image, and they are processed in sequence. If you place the USER configuration before the application installation instructions, your build will fail for lack of permissions.
If not using the ContainerAdministrator account is your goal, but you want to also provide more access to the user you want to use, there’s also the option to create a new user account:
RUN net user usarname ‘<password>’ /ADD
The above command could also be used in conjunction with granting the user access to a folder, or adding it to a different local group that has access granted to something. It all depends on your scenario.
Here’s the example of a more complete Docker file that leverages the change in the user account:
FROM mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2022
WORKDIR /webapp
COPY . .
RUN PowerShell Import-Module WebAdministration; \
New-WebApplication "WebApp" -Site 'Default Web Site' -ApplicationPool "DefaultAppPool" -PhysicalPath "C:\WebApp"
USER ContainerUser
Hopefully this helps better understand the usage of user accounts on Windows containers. Making sure your containers run with the security best practices is so important these days, and this is just a minor thing that can help a lot in terms of upping your security game. For more information, check out our documentation.
Let us know what you think in the comments section below!
