Step-by-step: Creating a new test environment for gMSA on AKS

[Vinicius Apolinario]

Microsoft recently announced a new feature that will help customers move existing applications to Azure Kubernetes Service (AKS) – Group Managed Service Accounts (gMSA). In a nutshell, gMSA allows applications that are Active Directory (AD) dependent to be containerized. By default, containers don’t understand AD as they can’t be domain-joined. With gMSA, we give the underlying container host the task of authenticating the application inside the container. This feature is currently on Public Preview on AKS.

However, as you can imagine, to even try gMSA on AKS you need to setup a fairly complex environment. You need an Azure vNEt, an AKS cluster, a VM working as Domain Controller, and both the Windows nodes on your AKS cluster and the Domain Controller must be on the same vNet.

With that in mind, I decided to make the process of spinning up that environment easier. If nothing else, this exercise might also give you some cool insights into how to use PowerShell to manage Azure resources.

Disclaimer: The below step-by-step guide should not be used for production environments. It’s intended to facilitate the process of spinning up a test environment to try the gMSA on AKS feature.

Getting started

We’ll be using PowerShell to automate the whole process, so to get started, let’s authenticate your Azure Subscription on a PowerShell session:

$Az_Sub = Read-Host -Prompt 'Please provide the Azure subscription ID to be used'
Connect-AzAccount -DeviceCode -Subscription $Az_Sub

Next, we’ll create a Resource Group to deploy all the necessary components:

$RG_Name = Read-Host -Prompt "Please provide the Resource Group Name"
$RG_Location = Read-Host -Prompt "Please provide the Resource Group Loation"
New-AzResourceGroup -Name $RG_Name -Location $RG_Location

Azure vNet

An important aspect of the Azure vNet is that you could use the vNet that is created by default when you create a new AKS Cluster. However, since we’ll be adding another VM to that vNet and in a real-world scenario you would probably need to configure a VPN, Peering, or Express Route, you should instead create a vNet that you manage, not Azure. I discussed this on a previous blog post. With that said, let’s create a vNet:

$vNet_Name = Read-Host -Prompt "Please provide the vNet Name"
$vnet = @{
    Name = $vNet_Name
    ResourceGroupName = $RG_Name
    Location = $RG_Location
    AddressPrefix = '10.0.0.0/16'    
}
$virtualNetwork = New-AzVirtualNetwork @vnet

Now let’s create a subnet config:

$Subnet_Name = Read-Host -Prompt 'Please provide the name of the Subnet to be created under the Azure vNet. This subnet will be used by Windows nodes on AKS as well as your DC'
$subnet = @{
    Name = $Subnet_Name
    VirtualNetwork = $virtualNetwork
    AddressPrefix = '10.0.0.0/16'
}
$subnetConfig = Add-AzVirtualNetworkSubnetConfig @subnet

With the subnet configuration in place, let’s associate the subnet to the vNet:

$virtualNetwork | Set-AzVirtualNetwork

Deploying an AKS cluster to the existing vNet

Now that we have the vNet in place, we can deploy an AKS cluster. In our case, we’ll deploy a simple cluster with the default configuration for most of the settings. You can customize the deployment below according to your needs.

$AKSCluster_Name = Read-Host -Prompt 'Please provide the name for the AKS cluster'
$Username = Read-Host -Prompt 'Please create a username for the administrator credentials on your Windows Server containers'
$Password = Read-Host -Prompt 'Please create a password for the administrator credentials on your Windows Server containers' -AsSecureString
$vnetinfo = Get-AzVirtualNetwork -Name $vNet_Name -ResourceGroupName $RG_Name
$subnetid = $vnetinfo.Subnets[0].Id
New-AzAksCluster -ResourceGroupName $RG_Name -Name $AKSCluster_Name -NodeCount 2 -NetworkPlugin azure -NodeVnetSubnetID $subnetid -ServiceCidr '10.240.0.0/16' -DnsServiceIP '10.240.0.10' -NodeVmSetType VirtualMachineScaleSets -GenerateSshKey -WindowsProfileAdminUserName $Username -WindowsProfileAdminUserPassword $Password

Now that we created the AKS cluster, let’s create a Windows node pool. In our case, we’re creating the node pool with just one node to save on the Azure cost and speed up the process.

$AKSPool_Name = Read-Host -Prompt 'Please provide the name of the node pool that will host your Windows nodes (lowercase only, limited to 6 characters)'
New-AzAksNodePool -ResourceGroupName $RG_Name -ClusterName $AKSCluster_Name -Name $AKSPool_Name -VmSetType VirtualMachineScaleSets -OsType Windows -Count 1

Create a new Azure VM

Once your AKS cluster is deployed, we need to deploy a VM to the same vNet (so the Windows nodes on your AKS cluster can talk to it). This VM will then be promoted to Domain Controller for your AD.

$VM_Name = Read-Host -Prompt 'Please provide the name of the VM that will be used later as a Domain Controller'
Write-Host 'Please provide the credentials to be used on the Azure VM'
$cred = Get-Credential
New-AzVM -ResourceGroupName $RG_Name -Location $RG_Location -Name $VM_Name -VirtualNetworkName $vNet_Name -SubnetName $Subnet_Name -Credential $cred -Image Win2019Datacenter -Size 'Standard_D2_v3' -PublicIpAddressName 'gMSADCPublicIP' -OpenPorts 3389

Once the VM is created, download the RDP file from the portal to connect to the VM – the next steps must be completed from a PowerShell session inside that VM.

Promoting the VM to Domain Controller

From inside the VM, let’s run the AD commands to promote this server to a Domain Controller and create our new forest domain:

Install-windowsfeature -name AD-Domain-Services -IncludeManagementTools
Write-Host 'Warning: Your VM will restart after this operation. Please save any In Progress work.'
$SafeModeAdministratorPassword = Read-Host -Prompt "DSRM Password" -AsSecureString
$Domain_DNSName = Read-Host -Prompt 'Please provide the DNS name for the new forest'
$Netbios = Read-Host -Prompt 'Please provide the Netbios name for the domain'
Install-ADDSForest -CreateDnsDelegation:$false -DatabasePath "C:\Windows\NTDS" -DomainMode "WinThreshold" -DomainName $Domain_DNSName -DomainNetbiosName $Netbios -ForestMode "WinThreshold" -InstallDns:$true -LogPath "C:\Windows\NTDS" -NoRebootOnCompletion:$false -SysvolPath "C:\Windows\SYSVOL" -Force:$true -SkipPreChecks -SafeModeAdministratorPassword $SafeModeAdministratorPassword

Please note the VM will restart after you run the above.

Try the gMSA on AKS feature

Now you have what’s needed to try out gMSA on AKS. From now on, you can follow the documentation available. You can continue to use the same PowerShell session you’ve been using so far, but keep in mind the gMSA on AKS PS module will also need you to login with Azure CLI.

At the end of the documentation page, you’ll notice there’s a sample app that validates if the whole authentication process is happening correctly. If the page opens and shows the information about the user that was authenticated, the whole process above worked fine.

Let’s collaborate!

Instead of just publishing this blog post, I decided to put this content on GitHub. There are two benefits:

• You can download the script files and run them instead of copying/pasting the above commands one-by-one.
• If you have a suggestion on how to make this script better, just clone the repo, work on your suggestion and open a PR so I can merge into the existing content.

Hopefully this is useful to you. Let us know in the comments section!