This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
Customers are increasingly finding value in migrating their Windows Server workloads to Kubernetes in both the cloud and on the edge. We’re giving this “lift and shift” scenario, as it’s often called, a boost with the public preview of group Managed Service Accounts (gMSA) for Windows containers on Azure Kubernetes Service (AKS).
What is gMSA on AKS and how does it work?
Many modern containerized applications require an Active Directory (AD) integration. Previously, customers did not have the option to use gMSA on AKS as a support method for domain joining of their Windows containers, largely due to their ephemeral nature. The initial preview of gMSA on AKS allows Windows containers to use the AKS host to perform the authentication on their behalf. Windows nodes had to be domain-joined, which led to the need to re-join the nodes after node upgrade or cluster scaling.
With this public preview, based on your feedback, we are introducing a more user-friendly structure for Windows containers on AKS. Our managed Kubernetes service on AKS provides an improved management experience for Windows containers using gMSA, including:
- No need to manually domain join nodes
- Nodes can be easily redeployed using new images
- No need to reconfigure AD objects after scaling nodes up or down
- Easier end-to-end process to configure gMSA
Here is how it works:
- The portable user identity is stored in Azure Key Vault
- A new component called Container Credential Guard (CCG), which lives on the node, uses the portable user identity to acquire the gMSA account from AD and give it to the containers
This process allows the applications running in a pod to use the AKS nodes to perform the authentication on its behalf in a secure way. For more information on how the gMSA architecture works, please refer to the gMSA documentation.
Improving the gMSA experience
Configuring gMSA on AKS requires a few key components: an AKS cluster, Active Directory, Azure Key Vault, credential specs, and more. It is easy to miss some details which impact the experience of using gMSA on AKS. For that reason, we created a new PowerShell module that streamlines the process of configuring gMSA on AKS.
The module takes users through the configuration of gMSA on AKS by collecting all the necessary parameters for later use. From there, users can copy and paste the PowerShell cmdlets to configure the environment following our documentation. The module can configure the gMSA account on Active Directory, finalize any gMSA related config on the AKS cluster, deploy and configure an Azure Key Vault, and configure the necessary access and authorizations so your AKS nodes can properly access the Azure Key Vault secrets.
Furthermore, the module provides a validation cmdlet that spins up a new pod on the cluster, checks the nodes, and returns information on how these nodes have dealt with DNS resolution on Active Directory and the Kerberos tickets stored - ensuring that the gMSA account successfully authenticated against your Domain Controller. In addition to this, the module provides a way to retrieve the gMSA related logs from the nodes so that you can further troubleshoot the environment in case something is not working.
Finally, the module provides a sample application in case you just want to see gMSA working on AKS but does not have an actual application to try it on. The sample application is a simple IIS deployment on which a page has Windows authentication set up. When IIS tries to reach for a domain controller to authenticate the user, the gMSA process explained above takes place and only after the user is authenticated, the content is shown.
We’ve made this PowerShell module to simplify the process of deploying gMSA on AKS. The guidance on how to use the module is on our docs page.
We hope you are as excited about this announcement as we are! This is the cloud-native and container-native way of doing Active Directory. We are incredibly thankful for the feedback we received from the community, which we used to evolve this important Windows functionality. We are always finding ways to improve identity for Windows Containers and your feedback is always critical in shaping its future evolution. As always, please tell us about your experience and do not hesitate to reach out if you have any questions - either below in the comments section or on our GitHub repo.
If you are curious about how gMSA can be used for Windows containers on AKS on Azure Stack HCI (AKS-HCI), check out our blog post on that topic from earlier this year.
Cheers,
Vinicius Apolinario, Justin Davies, Muzz Imam, Margarit Chenchev, Matthew Palko
(The Windows Containers and AKS team)