Recently I talked to a customer about their deployment of gMSA on Azure Kubernetes Service (AKS). This customer was having trouble when trying to run their deployment on AK, and the goal was to identify where the issue was. While discussing with the customer, it occurred to me that sometimes it’s hard to say if the issue is with the configuration of the underlying Kubernetes environment, or if it’s an issue with the application the customer was trying to deploy. To that end, I created a containerized sample app to test if the gMSA config is working or not.
This sample app is actually nothing more than the IIS base container image, with a new virtual directory with Windows authentication enabled, and a ASP.Net page that simply shows which user has authenticated to that page. In fact, this is the same that we used on the gMSA AKS PowerShell module.
gMSA Sample container image
To make things as simple as possible, I have published the final image to be used on Docker Hub. This way, you don’t even have to build the image yourself. You can simply pull it:
docker pull vrapolinario/gmsasampleapp:ltsc2022
If you are running in a Windows Server 2019 node, you can use the alternative tag:
docker pull vrapolinario/gmsasampleapp:ltsc2019
If you want to test a simple Windows host configuration for gMSA, you can run this image using:
docker run --security-opt "credentialspec=file://
.json" --hostname -d -p 8080:80 vrapolinario/gmsasampleapp:ltsc2022
You can then open a browser and point it to http://127.0.0.1. Upon opening the page, you should be requested to authenticate with a username and password. If either the authentication fails or you are not requested to provide the credentials, then there’s something wrong with your configuration.
To better understand what are the requirements for gMSA to work, check out the documentation that includes troubleshooting guidance.
Using this sample on AKS
The deployment of gMSA on AKS is much different than a single node, but the underlying architecture is pretty much the same (The main difference from single nodes is that AKS uses non-domain joined hosts). There’s a lot of documentation for gMSA on AKS, including our PowerShell module built for this.
Once you have gMSA configured on your AKS cluster, all you need is a YAML spec to deploy the image above. I created one for this purpose:
apiVersion: apps/v1 kind: Deployment metadata: name: gmsalm-demo labels: app: gmsalm-demo spec: replicas: 1 template: metadata: name: gmsalm-demo labels: app: gmsalm-demo spec: nodeSelector: "kubernetes.io/os": windows securityContext: windowsOptions: gmsaCredentialSpecName: credspec containers: - name: gmsalm-demo image: vrapolinario/gmsasampleapp:ltsc2022 imagePullPolicy: IfNotPresent ports: - containerPort: 80 selector: matchLabels: app: gmsalm-demo --- apiVersion: v1 kind: Service metadata: labels: app: gmsalm-demo name: gmsalm-demo namespace: default spec: ports: - port: 80 targetPort: 80 selector: app: gmsalm-demo type: LoadBalancer
The YAML spec above will deploy the same container image as described above, but it will map the credential spec to be used (You might need to change the value for the credential spec name for your environment). Just like the example above, you should check the IP address of your service to open on a browser:
kubectl get service
Once you get the IP address for your service, open a browser and see if authentication will be required. Just like before, if you can authenticate correctly, then congrats, your environment has been properly configured.
Testing if the gMSA configuration on AKS is correct or not might be challenging if you don’t have an app to test – or that you know works properly on Windows containers. This sample app is great, simple way to figure that out.
I hope this is useful for you. Let us know in the comments!