We’re very pleased to announce that Group Managed Service Account (gMSA) for Windows containers with non-domain joined host solution is now available in the recently announced AKS on Azure Stack HCI https://github.com/Azure/aks-hci/releases/tag/AKS-HCI-2104!
The Journey
Since the team started the journey bringing containers to Windows Server several years ago, we have heard from customers that the majority of traditional Windows Server apps rely on Active Directory (AD). We have made a lot of investments in our OS platform, such as leveraging https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/service-accounts-group-managed to give containers an identity and can be authenticated with Active Directory. For example, this blog showcased improvements in the Windows Server 2019 release wave: What's new for container identity. We have also partnered with the Kubernetes community and enabled https://kubernetes.io/docs/tasks/configure-pod-container/configure-gmsa/. This is extremely exciting news. But this solution needs Windows worker nodes to be domain joined with an Active Directory Domain. In addition, multiple steps need to be executed to install webhook and config gMSA Credential Spec resources to make the scenario working end to end.
To ease the complexities, as announced in this blog on What’s new for Windows Containers on Windows Server 2022, improvements are made in the OS platform to support gMSA with a non-domain joined host. We have been working hard to light up this innovation in AKS and AKS on Azure Stack HCI. We are very happy to share that AKS on Azure Stack HCI is the first Kubernetes based container platform that supports this “https://docs.microsoft.com/en-us/azure-stack/aks-hci/prepare-windows-nodes-gmsa” end-to-end solution. No domain joined Windows worker nodes anymore, plus a couple of cmdlets to simplify an end-to-end user experience!
“gMSA with non-domain joined host” vs. “gMSA with domain-joined host”
| gMSA with non-domain joined host | gMSA with domain-joined host |
|
|
|
|
|
Simplified end-to-end gMSA configuration process by built-in cmdlets
In AKS on Azure Stack HCI, even though you don't need to domain join Windows worker nodes anymore, there are other configuration steps that you can't skip. These steps include installing the webhook, the custom resource definition (CRD), and the credential spec, as well as enabling role-based access control (RBAC). We provide a few PowerShell cmdlets to simply the end-to-end experience. Please refer to https://docs.microsoft.com/en-us/azure-stack/aks-hci/prepare-windows-nodes-gmsa#configure-gmsa-for-windows-pods-and-containers-in-the-cluster
Getting started
We have provided detailed https://docs.microsoft.com/en-us/azure-stack/aks-hci/prepare-windows-nodes-gmsa#before-you-begin on how to integrate your gMSA with containers in AKS-HCI with non-domain joined solution.
- Preparing gMSA in domain controller.
- Prepare the gMSA credential spec JSON file (This is a one-time action. Please use the gMSA account in your domain.)
- Install webhook, Kubernetes secret and add Credential Spec.
- Deploy your application.
If you are looking for this support on AKS, you can follow this entry on AKS Roadmap https://github.com/Azure/AKS/issues/1680.
As always, we love to see you try it out, and give us feedback. You can share your feedback at our https://github.com/microsoft/Windows-Containers/issues , or contact us directly at mailto:win-containers@microsoft.com.
Jing
Twitter: https://twitter.com/JingLi00465231
