gMSA for Windows Container - 觀念

提醒：本篇文章會用到 Microsoft Active Directory & Docker & Kubernetes 的技術名詞。

前言

相信大部份 Windows 使用者過去都接觸過或聽過 Microsoft Active Directory （以下簡稱：AD）服務，我曾經聽過 Novell （上古神獸公司，LDAP 推廣公司之一）人員說：Microsoft 讓 Directory 概念深入到全世界企業。做為 Microsoft 核心服務之一的 AD，有許多 authentication & authorization 的功能都圍繞著 AD，例如：NTLM in IIS，Windows Desktop login，MSSQL authentication，Windows Cluster，Exchange (這又是另一段故事了），ADFS （註四）等。

題外話一，因為 gMSA for my Kubernetes Windows node，所以我們 team 大概是這一年來公司內用 gMSA 最兇的人，Windows node 就是會自動加加減減。

題外話二，用 gMSA 要對 AD 有一定程度的了解，筆者過去當過很長一段時間的 AD admin 並且使用 Kubernetes 一段時間，這二種經驗才讓筆者可以順利導入 gMSA for Kubernetes。

為什麼 gMSA

一般來說 Windows 平台開發者常常把 AP 寫成 Windows Service 或用 IIS 做 Web，並利用已經加入 AD 的 Server 提供 user 的 AD account authentication，但這情況到了初期 container 世界有了顛覆傳統的變化，因為 container 不能加入 AD，就算你可以在 AP 裡直接寫 credential 去 access 後面的 resource （例如：DB），但沒有加入 AD 的 container 無法解決怎麼驗證 user 的 AD account & AD password，因為 AD 不認為這個 container 是 authorized computer，當然你可以考慮用 LDAP，但這就代表要重寫 Code，並且犧牲部份功能，用 LDAP + Service account 安全性也降低。

如何用 gMSA

一旦 Infra ready，當你在佈署時，在 Kubernetes deployment YAML 裡宣告要使用 gMSA ，你的 Pod 就像加入 AD Domain 的 computer，就是這麼簡單。

傳統上，一台 computer (Service or Workstation）要成為 AD domain 一員，需要下述幾個步驟

• 在 Domain Controller 上建立 Computer Object （可省略）。
• 在 Server 或 Workstation 上執行加入 AD 流程 （GUI or Cli），此時它就會跟 AD 建立一個 trust relationship。
• 重開機完成加入 AD domain 流程。

但這樣做法在 container 完全行不通，因為 container 的 lifecycle 完全不是這麼一回事，你無法在 container 做上述步驟，就算你真的在 Docker 上做到了，但到 Kubernetes 上就完完全全做不到，就算就算你真的用很怪的方法去做，筆者相信這會失去 Kubernetes 上 Pod 的特性（真的做到也請分享，筆者佩服啊）。

Microsoft 也發現這個問題，所以在近年推出了 gMSA，概念上 gMSA 是讓 Domain Computer 可以使用 AD account ，它的特性如下：

AD 部份

• 要在 AD domain 啟用 gMSA 的功能。
• gMSA 在 AD 裡的名稱是 $ 結尾，Microsoft 有提過 gMSA 是從 Computer Object 變形而成的。
• 在設定資源權限時，物件類型要選 Service Account，例如在設定 MSSQL DB 權限時。
• Account 的使用權是套用在 Domain Computer 上，所以 Windows node 要 AD domain。
• 密碼的管理將由 AD domain controller 控制，也就是說當你要 Access MSSQL DB，再也不用換密碼了，
• 因為 AP 的 connection string 不用放 credential，就不用擔心 password leak 的問題，因為沒有人知道密碼，這相對更安全。
• 更快速。因為 gMSA 可以授權給 AD group 使用，所以只要你的 domain computer 是這 AD group 一員就可以立即使用，也就是說自動化要規劃好（註一）。
• 一台 Domain computer 可以用多個的 gMSA。
• 如果有 Windows node auto scaling 的需求，建議跟 AD admin 申請一個 OU 的 delegation，要有 computer Object creation and removal 權限。

Docker 部份

• 加入 AD 的 Windows Docker host (VM 以來的習慣稱法）上的 container 都可以透過參數使用 gMSA （註五）。
• 承上，目前所知無法在 Docker host 上限縮部份的 Docker container 可以或不可以使用 gMSA。

Kubernetes 部份

• 一個 Kubernetes Cluster 可以用多個 gMSA，但每一台 Windows node 都要被授權使用那些 gMSA。
• 在 Kubernetes 上，Kubernetes cluster admin 透過 CRD 管理那一個 Namespace 的那一個 Service Account 可以用那一個 gMSA，Windows Pod 宣告要用該 Namespace 下被授權的 Service Account。這邊的關係要清楚，要不然得不到你要的結果（註五）。
• 宣告用 gMSA 的 Pod 在啟動時會呼叫一個 Kubernetes Cluster 內的 web service，該 Service 會檢查這個 Namespace 裡的這個 Pod 可不可以用宣告的 gMSA。
• 承上，如果沒權限使用該 gMSA，Cluster 不會允許你的 Pod 長出來。
• 在 Cluster 內的 gMSA web service，目前的版本是只能運作在 Linux node（註二）。
• Kubernetes Deployment / Cronjob / DemandSet / Stateful 產生出來的 Pod 都可以使用 gMSA （註三）。
• 在 2020/12 目前為止，Linux Pod 不能用 gMSA，因為它不是跑在 Windows node 上。未來不知道，也許 Microsoft 又丟出震撼彈。

就筆者自己的經驗，要用 gMSA 前 Kubernetes admin 需要先把環境規劃好，尤其是 Windows node auto scaling 的加入 AD domain 自動化。接著就是規劃好 Cluster 內的 gMSA 使用控管，至於 AP team 就是宣告要用那一個 gMSA。

我想 Microsoft 也企圖透過 gMSA ，讓 AD 與 Windows container 在 Container 世界有一席之地。

到此，由於篇幅長度的關係本篇著重於觀念分享，如果有任何問題都歡迎提出，下一篇「 gMSA for Windows container 部曲二：實做」筆者將會介紹怎麼實做。

補充

註一：是的，AD group 可以包含 AD computer！！！驚訝吧。在實做上，把要使用的 gMSA 都挷在一個 AD group，如此在自動加入 AD domain 後，只要再加一條加入 AD group 的自動化。

註二：如筆者在 Kubernetes for Windows 文章所提，gMSA 需要 Linux node。

註三：筆者遇過不少人對各種類形的 Pod 不太了解，關於這個問題筆者會寫一個有關各種 Pod 的文章，希望可以幫助大家。

註四：ADFS，Microsoft 推出的 Identity Provider，全名 Active Directory Federation Services，顧名思義他就利用 AD 來做到 SSO by SAML Assertion。早期在企業內推廣的時候，人們都覺得他非常的神秘。

註五：要用 gMSA 前需要先知道 CredentialSpec，可以透過下述的 command 產生，這個 spec 可以一直使用，新的 gMSA 就再產生一次。它其實是將 AD 裡的資訊整理後產一個檔案。

New-CredentialSpec -AccountName WebApp01