執行容器化的 Windows 工作負載

  • 6 分鐘

Contoso 依賴 AD DS 作為 Windows 和 Linux 工作負載的身分識別提供者，並以 Kerberos 作為主要驗證通訊協定。 資訊安全小組要求您調查將 Azure Stack HCI 上的 AKS 託管的容器化工作負載與整合至 Contoso 的 AD DS 環境的選項。 考慮到您想要將以 Windows 為基礎的節點和容器部署到 Kubernetes 叢集，您要判斷這種情況下可能會有何種程度的整合。

將 Azure Stack HCI 上的 AKS 內的 Windows 容器與 AD DS 整合

在某些情況下，在 Kubernetes pod 中執行的容器化 Windows 應用程式可能需要存取 AD DS 保護的資源。 這類功能需要使用 AD DS 網域型身分識別，才能成功完成驗證和授權工作。 若要執行此身分識別，您可以使用群組受管理的服務帳戶 (gMSA)。

相較於管理 Windows 服務的身分識別以及需要自行驗證的應用程式，gMSA 提供數項優點，包括自動密碼變更、簡化的設定和維護，以及委派管理的支援。

若要讓 pod 使用 gMSA 進行驗證，請將將裝載 pod 的所有 Windows Server 型 Kubernetes 背景工作節點聯結至 AD DS 網域。 透過安全殼層 (SSH) 來連線至每個節點，然後使用聯結參數執行 netdom.exe 命令列公用程式，以執行網域加入。

其餘的程式與任何包含 Windows Server 背景工作節點的 Kubernetes 叢集中相同，且具有下列高階步驟：

  1. 在 AD DS 中布建 gMSA，並將它指派給 Windows Server 節點。
  2. 定義代表 AD DS gMSA (GMSACredentialSpec) 的自訂 Kubernetes 資源類型。
  3. 設定以 webhook 為基礎的機制，以自動填入並驗證 pod 和容器的 GMSACredentialSpec 參考。
  4. 根據 GMSACredentialSpec 資源類型建立自訂資源。
  5. 定義叢集角色，以啟用 GMSACredentialSpec 資源的 RBAC。
  6. 將角色指派給 AD DS gMSA，以授權其對應 GMSACredentialSpec 資源的使用方式。
  7. 將 GMSACredentialSpec 資源的參考包含在用來進行 AD DS 驗證的 pod 定義中。

注意

若要啟用 gMSA 支援，Kubernetes 叢集的名稱不能超過三個字元。 此條件約束的結果是來自已加入網域之電腦名稱稱的15個字元限制。

知識檢查

1.

Contoso 的資訊安全小組要求您調查這些選項，以針對在 Azure Stack HCI 上的 AKS 裝載的 Windows 型容器化工作負載執行以 AD DS 為基礎的驗證。 首先，將包含 Windows Server 節點的 Kubernetes 叢集部署到您的 Azure Stack HCI 叢集中。 您接下來應該怎麼做？