gMSA for Windows Container — concept

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

Before start

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

How to gMSA

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

  • 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

  • Docker host admin cannot limit docker container to use particular gMSA only.

In the Kubernetes

  • 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.

Appendix