gMSA for Windows Container — concept

Aaron Hsieh
4 min readDec 13, 2020

Reminder: this article contains technique terms of Microsoft Active Directory, Docker, Kubernetes.

Before start

I believe most of Windows user who knows Microsoft Active Directory (abbreviation below: AD) service. I use to heard Novell people who said: Microsoft broadcast Directory concept to the Worldwide corp.

As core product of Microsoft, a lot of product authentication and authorization around AD, e.g. NTLM in IIS, Windows Desktop login, MSSQL authentication, Windows Cluster, Exchange (there is story…), ADFS (note 1)…etc.

By the way. Due to gMSA for my Kubernetes Windows node, therefore our team should be most used gMSA user since last year. Additionally, gMSA implementation that needs AD knowledge. I use to be AD admin for a long time, and have Kubernetes experience. Therefore, I could smoothly implement gMSA for Windows container.

Why gMSA

Generally, Windows platform programmer usually build AP as Windows service and leverage Domain computer for AD account authentication. This kind of practice that encountered big impact since early stage of container world. Due to container cannot join AD, even you put credential to access DB resource. You still cannot solve user AD authentication issue because of container is not authorized computer. Maybe you can consider LDAP. But that means you need to re-write your code. If you put your domain service account inside the configuration file that decreases security.

How to gMSA

Once gMSA ready, You just need to declare gMSA into your deployment YAML file. You pod will be like joined domain computer immediately.

Tranditionally, system admin needs to perform the following action for domain joining.

  • Create computer object on Domain controller (you can skip this action).
  • Perform domain joining to create trust relationship between AD and computer.
  • Reboot computer to complete domain joining.

Regarding above action, it is impossible to perform them inside container because of container lifecycle that is different concept. Even you implemented in the Docker. However, you cannot perform the same action on Windows Pod.

I would say that Microsoft realized this issue, therefore we saw the gMSA in recent years. Ideally, gMSA is to allow domain computer to use AD account. There are the following features.

In the AD

  • You need enable gMSA in the AD domain
  • gMSA name is end with “$”. It is similar computer object.
  • When setup permission, you need to choose service account object type, e.g. MSSQL DB permission assignment.
  • The account authorization binds at domain computer tier. Therefore, Windows node needs to join AD domain.
  • Password is managed by AD domain controller. That is to say, you don’t need to change password any more.
  • Due to no password in the connection string OR configuration file. You don’t need to worry about password leak issue because of no one know password. It is more secure.
  • Due to AD can assign to a group, therefore you just need to ensure your Windows nodes are member of this AD group. Regarding this requirement, you might need to plan automation well.
  • A domain computer can be assigned to multiple gMSA.
  • If you need Windows node auto scaling, please request an delegated OU with computer object creation/removal permission. Arrage a well talk meeting with AD admin. :)

In the Docker

  • All containers on the machine joining the domain that can get gMSA permission.
  • Docker host admin cannot limit docker container to use particular gMSA only.

In the Kubernetes

  • A Kubernetes cluster can configure multiple gMSA. All of Windows node need to join AD domain.
  • Kubernetes Cluster admin leverages CRD (custom resource definition) to manage which one service account of namespace to get which one gMSA permission. Please have relationship overview, otherwise you might get unexpected result.
  • When RestfulSet (or Job) declares gMSA, it will call a Kubernetes inside web service for authorization. If RestfulSet (or Job) does not have permission, Cluster won’t allow your pod creation.
  • Currently, gMSA web service only can run on the Linux node.
  • Till 2020/12, Linux pod cannot use gMSA because of it is not on Windows node. Maybe Microsoft will allow Linux Pod in the future. :P

From my experience, Kubernetes admin needs to plan infra well. Especially, Windows node auto scaling with domain joining. Once infra ready, cluster admin need to manage gMSA assignment.

From my point of view, I would say Microsoft is trying to leverage to gMSA for AD plus Windows container. I believe they want more market share.

At the end. This article focus on concept. I will share “How to” in the next article.


note 1: ADFS is a Microsoft modern authentication solution.