This post is originally published as article within SDN Magazine on October 13th, 2017.
During the past year I supported several clients in their journey toward Containerized Delivery on the Microsoft stack. In this blogseries I’d like to share eight practices I learned while practicing Containerized Delivery on the Microsoft stack using Docker, both in a Greenfield and in a Brownfield situation. In the fourth blogpost of this series I want to talk about Group Managed Service Accounts.
PRACTICE 4: Group Managed Service Accounts
A lot of existing .NET applications make use of Domain Accounts for authentication, e.g., connecting with SQL Server via Windows Integrated Authentication. The fact that Windows containers cannot be domain-joined may surprise you, but this is by design. Joining a computer to the AD is something that we do for long-term registration. Containers come and go very frequently on a machine and this is not what AD is designed for. Consequently, this could lead to registration issues. Luckily the Windows server team already had a solution in-place to make it possible to make use of Domain Accounts for external authentication from within a container. This solution is called Group Managed Service Accounts (gMSA).
The idea behind this solution is to create a so-called gMSA within Active Directory where you also specify which container hosts have access to this account. This can be a list of container hosts or a security group containing all container hosts that should be able to run a container using this account. The next step is to prepare the container hosts and test whether they can access the gMSA. After that, you have to install and make use of the CredentialSpec PowerShell module to store the required gMSA details in a correct (JSON credential spec) format on your container hosts.
Once the required gMSA details have been stored, you can make use of the stored gMSA credentials spec to authenticate external services under the given gMSA from within your container. The only thing you have to ensure within your container is that your services and other processes that need to access the external resource run as ‘Local System’ or ‘Network Service’. When you start your container on the container host you can execute a docker run command with the –security-opt “credentialspec=file://WebApplication1.json” argument in order to pass the appropriate credential spec on to your container. At the same time, the applications within your container can access the external resource. For an extensive walk-through, have a look at http://bit.ly/2tWGloy.
Interested in the next practice? See PRACTICE 5: Secure Containerized Delivery.