Active Directory and Kubernetes – everything you need to know about gMSA with Windows Containers

This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

Organizations with applications that use Active Directory (AD) for authentication and authorization typically encounter challenges when integrating them in containerized solutions like Azure Kubernetes Services (AKS). 

 

To use AD authentication, you can run your AD-based application on Windows containers with a group Managed Service Account (gMSA). Using Windows containers and gMSA minimizes the changes required which does reduce the cost and time to bring those applications to market.  

 

In this article we’ll look at: 

1. Primer on Windows Containers for legacy applications 
2. Challenges with containerizing AD-based applications 
   1. Scenario #1 - IIS application with AD integration 
   2. Scenario #2 - Multi-tier application with AD/Kerberos authentication 
3. Containerizing AD-based apps using gMSA for authentication 
   1. Scenario #1 (Web Server Scenario) 
   2. Scenario #2 (Multiple Services in a Container)  
4. When is gMSA not the right solution? 
5. Customer wins with gMSA 
6. How to get started 
7. Frequently asked questions 
   1. Does gMSA require my Windows node to be domain joined? 
   2. Do I need to configure plug-ins when running gMSA? 
   3. Can runAsUserName use a gMSA? 
   4. What’s the difference between gMSA and Pod Identity? 
   5. Are there any additional considerations for on-premises Windows container workloads? 
   6. Can I use gMSA to authenticate with a SQL Server database? 

 

Primer on Windows Containers for legacy applications 

Graphic showing how containers can run in the cloud or on-premises, supporting monolithic apps or microservices written in nearly any language.

Windows Server containers, launched in 2016 by Microsoft, are the hero container platform for containerizing legacy IIS apps (such as .NET Framework and .NET Core), Win32, Java and Visual Basic applications because of the minimal code level changes needed. 

 

The latest Windows OS is the Windows Server 2022 containers which is available on AKS, and it provides the latest security and performance improvements and is the recommended OS for Windows node pools on AKS.  

 

We support running Linux and Windows node pools in the same cluster. However, Windows Server 2019 and Windows Server 2022 can't coexist on the same node pool on AKS. You’ll need to create a new node pool to host the new OS version. 

 

You can read about how our customers achieved time and cost savings by migrating their legacy applications to Windows containers on AKS.

 

Challenges with containerizing AD-based applications 

Let’s discuss two popular AD-based application scenarios and their challenges with containerizing.  

 

Scenario #1 - IIS Application with AD Integration 

You have an IIS application that uses Active Directory and single sign-on to authenticate and personalize the experience for users.  

Typically, this would be accomplished by joining the Windows Server instance hosting IIS to Active Directory and configuring IIS to use the computer or a service account to authenticate.  

 

Scenario 2 - Multi-tier Application with AD/Kerberos Authentication 

You have a multi-tier application (e.g. IIS or a data processing app) where the various tiers use AD/Kerberos to authenticate amongst each other.  In this situation, you’d normally join the various Windows Server instances hosting these tiers to AD and permission each tier accordingly. 

 

Scenario 1 & 2 containerization challenges.

The challenge with containerizing these two types of applications lies in ensuring consistent identity management and access controls across containers.  

 

Unlike static Windows Server instances, containers can be transient and numerous which is beneficial in scaling up/down quickly and updating your workloads, however it does complicate the configuration and management of identity and access in Active Directory environments. For example: 

1. Dynamic Service Discovery and Configuration: Containers are dynamic and ephemeral, making it challenging to maintain consistent AD configurations. 
2. Secure Credential Management: Managing credentials and sensitive information in a containerized environment is critical. 
3. Automated Container Identity Management: This system should integrate with AD to ensure that each container has the correct identity and access rights, based on its role and function within the application. 

Containerizing AD-based apps using gMSA for authentication 

 

 

Let’s now expand on how you can leverage AD in a container environment with minimal changes. We created gMSA to provide an automated management of service account passwords and separate the AD identity. This allows applications running in a container environment (standalone and managed by Kubernetes) to authenticate with AD by using gMSA.  

 

Any service running as SYSTEM or NETWORK SERVICE will use the Windows Container's identity just like they use the domain-joined host's identity today.  This setup eliminates the need to store passwords or certificate private keys in the container image, mitigating the risk of accidental exposure. The container's ability to be redeployed across various environments – development, test, or production – without a rebuild for changing stored passwords or certificates streamlines the operations and ensures a secure consistent user authentication experience across the board.  

 

If we containerize the 2 example app scenarios highlighted previously - (1) IIS Application with AD Integration and (2) Multi-tier Application with AD- we can end up with a Web Server running in a container for the former and multiple services in a container in the latter. 

 

Let’s discuss our options to integrate these applications with AD and run in a single container.  

Scenario #1 (Web Server Scenario)

Imagine you have a web server running in a container. This web server needs to access a database on another server. To authenticate and access the database securely, the web server uses the container's gMSA identity which you can do by running it as 'Local System' or 'Network Service'.  

 

Scenario #2 (Multiple Services in a Container)

Suppose you have a container with two services: a file-sharing service and an email service. Both need to authenticate to different network resources using different identities for security reasons. In this case, you can configure your container with multiple gMSAs. Each service in the container can then use a different gMSA to authenticate to its respective network resource. 

 

You can run an IIS app pool, Windows service or console apps as Network Service. For more information on this, you can read the gMSA configuration page on Azure docs.  

 

When is gMSA not the right solution? 

There are also situations where your app uses AD but gMSA isn’t the right fit. Here are some scenarios:  

1. AD-based apps that rely on Group Policies. 
   1. Note: Group policies can be translated to dockerfiles which eliminates the need for group policies. 
2. Application is not dependent on Active Directory authentication 
3. Application using Azure Active Directory (Azure AD), then Azure AD Workload Identity (formerly known as Pod Identity) might be a better fit.  

Customer wins with gMSA  

We’ve seen customers cut down benefit greatly from leveraging gMSA, and this includes:  

1. Cutting down the effort and time to migrate their apps to K8s  
2. Moving fully to the cloud and saving on-prem infrastructure costs 
3. Delivering a better customer experience through faster developer productivity by standardizing their CI/CD and DevOps practices  

 

How to get started 

There are a number of excellent resources to help you set up gMSA for your windows workloads on AKS. Here’s the order of resources we recommend you go through to successfully set up:  

 

Learn how gMSA works: 

1. Create gMSAs for Windows containers [Virtualization docs] 
2. Configure your app to use a gMSA [Virtualization docs] 
3. Run a container with gMSA [Virtualization docs] 

 

Learn how to deploy gMSA on AKS 

For Azure Kubernetes Service, we created a PowerShell module that configures the multiple components needed, greatly simplifying the process of deploying gMSA on AKS. The usage of this module can be broken down into three parts: 

1. gMSA on Azure Kubernetes Service [Virtualization docs] 
2. Configure gMSA on Azure Kubernetes Service with the PowerShell module [Virtualization docs] 
3. Validate gMSA on AKS with the PowerShell module [Virtualization docs] 

 

If you don’t want to use the recommended PowerShell module, you can still configure gMSA on AKS by manually deploying all resources and configurations: 

• Enable Group Managed Service Accounts (GMSA) for your Windows Server nodes on AKS cluster [AKS docs]  

 

Deploy gMSA on AKS Hybrid for on-premises scenarios 

gMSA can also be used when containerizing Windows applications in on-premises environments with Azure Kubernetes Services Hybrid, running on Windows Server or Azure Stack HCI: 

• Configure group Managed Service Accounts (gMSA) for Windows containers with AKS on Azure Stack HCI and Windows Server [AKS Hybrid docs] 

 

Troubleshooting 

Finally, once you have gMSA configured but something goes wrong, check out the documentation on how to troubleshoot the environment: 

• Troubleshoot gMSAs for Windows containers [AKS docs] 

 

Examples and workshops 

We’ve also developed workshops to walk you through examples of setting up (1) an ASP.NET app running in an IIS server that is authenticated with gMSA and (2) a minimal IIS configuration which is running a Windows pod authenticated with Active Directory by using gMSA. 

1. gMSA sample application for Windows containers [Tech Community] 
2. gMSA on Azure Kubernetes Service workshop [GitHub] 

 

Frequently asked questions 

Does gMSA require my Windows node to be domain joined? 

No this isn’t required. We support gMSA for Windows containers on both domain joined and non-domain joined Windows nodes.  

When gMSA for Windows containers was initially introduced, it required the container host to be domain joined, however this limitation has been addressed. 

 

Do I need to configure plug-ins when running gMSA? 

When running Windows containers with gMSA on non-domain joined Windows nodes, a plug-in to retrieve the gMSA credentials is needed to implement the Container Credential Guard Interface.  

 

Fortunately, AKS and AKS Hybrid customers don’t need to worry about this implementation as it is native to the Windows nodes on AKS. Customers running Windows containers with gMSA on Windows nodes outside of Azure that are not domain-joined will need to implement a plug-in.  

 

You can consume the Container Credential Guard (CCG) API for your own solution or follow our recommendation to use the Container Credential Guard Azure Key Vault Plugin (CCGAKV Plugin) which the retrieves group managed service account (gMSA) credentials stored in Azure Key Vault to facilitate the domain-join process.  

 

Can runAsUserName use a gMSA?   

runAsUsername cannot be a domain user (or any user with a password as we don’t support passing in the password).  

The recommended best practice way of using runAsUserName would be to do so in the context of NETWORK SERVICE which would put it in the context of the GMSA.  

 

What’s the difference between gMSA and Pod Identity? 

gMSA is for supporting traditional AD-based applications that are being containerized. Pod Identity is intended to support modern applications that take advantage of Entra ID (formerly known as Azure AD) for authentication. 

 

For more information you can read Pod Identity or gMSA? Which one is best for you on Azure Kubernetes Service blog post. 

 

Are there any additional considerations for on-premises Windows container workloads? 

Yes. While you don't need to domain join a Windows worker node in AKS on Azure Stack HCI and Windows Server, there are other required configuration steps. These steps include installing the webhook, the custom resource definition (CRD), and the credential spec, as well as enabling role-based access control (RBAC role).

 

For more information, you can review the Configure group Managed Service Accounts (gMSA) for Windows containers with Azure Kubernetes Service on Azure Stack HCI and Windows Server page. 

 

Can I use gMSA to authenticate with a SQL Server database? 

Yes. Applications can use Active Directory gMSA to connect to SQL Server databases using Windows Authentication.  

You’ll need to:  

1. Create a gMSA in AD and configure the necessary permissions 
2. Configure gMSA on Azure Kubernetes Service 
3. Create a host Service Principal Names (SPN), MSSQLSvc/hostname, for your gMSA account 
4. Configure the SQL Server for gMSA Authentication, this involves changing the service account in the SQL Server Configuration Manager to the gMSA. 

For instructions on creating gMSA with SPNs, you can review the Create a group Managed Service Account section. Additionally, to learn about configuring the SQL Server Configuration to gMSA you can review the Secure AND Easy Service Account Management blog post. 

 

Conclusion 

If you’re looking to leverage the benefits of containers or Kubernetes for your applications that rely on Active Directory, you should consider migrating your application to Windows containers and use gMSA to handle your AD authentications.  

 

We’d love to hear your feedback on gMSA for Windows Containers, you can leave an issue on the Windows Container GitHub repository.