This post has been republished via RSS; it originally appeared at: Containers articles.
At Ignite, we announced the Public Preview of a very anticipated feature for Azure Kubernetes Service (AKS) - support for Group Managed Service Accounts (gMSA). This preview allows customers to kick the tires on bringing existing applications that require Active Directory authentication to a modern platform in the cloud with AKS. However, in our customer engagements, we’re seeing some common issues around networking that I’d like to clarify in this blog post.
Where is my Domain Controller?
When you think about Active Directory (AD), there’s another key technology that goes with it - DNS. DNS is used for name resolution and in Windows environments with AD it is also used for service locator. That means for Windows instances that are domain joined, DNS will be used to find the Domain Controller. The Windows instance queries its primary DNS server (secondary is used only if primary did not respond) to find a SRV type of entry in the DNS for the domain. The DNS server then returns a list of Domain Controllers that are available for that Windows instance. Of course, this is a very simplistic view on how the process works. The full process includes ensuring the servers returned are on the same site, and much more.
The key point here though, is that DNS is used by the Windows instances to find a DC available, so they can authenticate themselves, apps, etc. With gMSA on AKS that’s not different. While the nodes on AKS are not domain-joined, they still get a primary (and if you provide, a secondary) IP address for the DNS server to be used on their networking settings. That DNS server should be able to resolve the domain you want to use for the gMSA configuration. In most cases, in a regular AD environment, that means the DNS server is also the DC - although that not’s a fixed requirement and some customers might have these roles on different servers.
Notice that the process above is just a name resolution. There’s no routing of the authentication process for that. What that means is: If you have a dedicated DNS server for your AD domain, your AKS nodes need to be able to perform a DNS query against that DNS server to find the DC address. DNS ports need to be open between AKS nodes and DNS server. If you have DNS and DC collocated (most common), the same applies, but you also need the connectivity described in the section below.
AKS node and DC communication
Once your AKS node can resolve the DNS domain and find the DC, it needs to perform AD authentication against that DC. When you do this on your local on-premises environment, most likely, the DC is available to the Windows instances with no firewall in-between. When it comes to resources on the cloud, that might not be the case. So, the first thing to think about here is DC placement. You have a few options:
- You can place a (or more than one for high availability) DC on the same network as your AKS nodes. This is a preferred mode for performance. Of course, if the domain you’re hosting for gMSA has multiple DCs outside of this network, you also need to think about how these will replicate to the other DCs on your environment. If you’re not familiar with Active Directory Sites and Services, please take a look at our documentation.
- If your DCs are located on-premises and you are not deploying a new one closer to the AKS nodes, you can configure a VPN/Express Route between the Azure vNet on which your AKS nodes reside and the on-premises environment where the DCs are.
- If your DCs are on another Azure vNet, you can configure a VPN or vNet peering between these vNets.
- Finally, if your environment allows, you can use Azure AD DS. Azure AD DS is a managed AD service and works for gMSA on AKS. For more information on Azure AD DS, check out our documentation.
The main point to be understood here is: There’s no magic for AD authentication when it comes to gMSA on AKS. Your AKS nodes need to be able to communicate with your DC just like any other Windows instance that authenticates against AD. If your DCs are close or far, it doesn’t really matter. Obviously, the preferred option is to place the DCs closer, but even if that’s not possible, all you have to ensure is that your Windows nodes on AKS can:
- Resolve your AD domain via DNS, and:
- Authenticate against your DCs.
For these to work, you need to plan carefully for that DNS and DC placement.
AKS is managed service - and so is its vNet
By now you might be thinking: Well, whatever I need, I’m just going to configure the Azure vNet the way I need for it to work. Let me stop you right there. Before making changes to the Azure vNet, remember that AKS is a managed service. What that means is that some configurations are managed for you and might be reset in case something changes. This is the case for Azure vNets that are created along with the AKS cluster.
When you’re creating a new AKS cluster you have the option to create a new vNet along with the cluster or select an existing one. If you choose to create the vNet along with the cluster, that means it is now a managed service as well and you should not be changing its configuration. If you plan to configure a VPN or vNet Peering for that vNet, you should create the Azure vNet separately, then select to use that Azure vNet when deploying your AKS cluster.
Hopefully these tips will help you better plan your gMSA deployment on AKS. Let us know what you think - as always, either below on the comments section or on our GitHub repo.