This post has been republished via RSS; it originally appeared at: Containers articles.
Identity is a crucial component of any application. Whether you’re authenticating users on a web app or trying to query data from a back-end server, chances are you’ll need to integrate with an identity provider. Containerized applications are no exception, which is why we’ve included support for Active Directory identities in Windows Containers from the beginning. Now that Windows Server 2019 has released, we’d like to show you what we’ve been working on the last 3 years to make Windows container identity easier and more reliable.
If you’d like to jump straight into the documentation on container identity, head on over to https://aka.ms/containers/identity
Improved Reliability
When we launched support for containers in Windows Server 2016, we set off on an adventure to redefine how people manage their apps. One of those innovations was the use of a group managed service account (gMSA) to replace the computer identity in containers. Before containers were a thing, you would typically domain-join your computer and use its implicit identity or a service account to run the app. With containers, we wanted to avoid the complexity of domain join since it would quickly become difficult to manage short-lived computer objects in Active Directory. But we knew apps would still need to use AD identities, so we came up with a solution to assign a gMSA to the container computer account at runtime. This gave the container a similar experience to being domain joined, but let multiple containers use the same identity and avoided having to store sensitive credentials in the container image.
As more customers started using gMSA with a wide variety of applications, we identified two issues that affected the reliability of gMSA with containers:
- If the hostname of the container did not match the gMSA name, certain functionality like inbound NTLM authentication and ASP.NET Membership role lookups would fail. This was an easy doc fix, but led to a new problem…
- When multiple containers used the same hostname to talk to the same domain controller, the last container would supersede the others and terminate their connections, resulting in random authentication failures.
To address these issues, we changed how the container identifies itself on the network to ensure it uses its gMSA name for authentication regardless of its hostname and made sure multiple connections with the same identity are properly supported. All you need to do to take advantage of this new behavior is upgrade your container host and images to Windows Server 2019 or Windows 10 version 1809.
Additionally, if you were unable to use gMSA identities with Hyper-V isolated containers in Windows versions 1703, 1709, and 1803, you’ll be glad to know that we’ve fixed the underlying issue in Windows Server 2019 and Windows 10 version 1809. If you can’t upgrade to the latest version of Windows, you can also use gMSAs with Hyper-V isolation on Windows Server 2016 and Windows 10 version 1607.
Better docs and tooling
We’ve invested in improving our documentation to make it easier for you to get started using gMSAs with your Windows containers. From creating your first gMSA account, updating your Dockerfile to help your app use the gMSA, and troubleshooting tips for when things go wrong, you’ll find it all at https://aka.ms/containers/identity.
As part of the documentation upgrade, we’ve also made it easier to get the Credential Spec PowerShell module. The source code still lives on GitHub, but you can now easily download it from the PowerShell Gallery by running Install-Module CredentialSpec. There are also a few improvements under the hood, including better support for child domains and improved validation of the account information.
Kubernetes Support
Finally, we’re excited to announce that alpha support for gMSA with Windows containers is shipping with Kubernetes version 1.14! Kubernetes takes care of copying credential specs automatically to worker nodes and adds role-based access controls to limit which gMSAs can be scheduled by users. While gMSA support is not yet ready for production use, you can try it by enabling alpha features as described in the Kubernetes gMSA docs.