将 Windows 容器的组托管服务帐户 (gMSA) 配置为使用 Azure Stack HCI 和 Windows Server 上的 Azure Kubernetes 服务

  • 项目

适用于：Azure Stack HCI 22H2 上的 AKS、Windows Server 上的 AKS

若要使用 AD 身份验证，可以为 Windows 容器配置组托管服务帐户 (gMSA) 以在未加入域的主机上运行。 组托管服务帐户是 Windows Server 2012 中引入的一种特殊类型的服务帐户，旨在使多台计算机无需知道密码即可共享一个标识。 Windows 容器无法加入域，但许多 Windows 容器中运行的 Windows 应用程序仍需要 AD 身份验证。

注意

若要了解 Kubernetes 社区如何支持将 gMSA 与 Windows 容器配合使用，请参阅配置 gMSA。

主机未加入域的容器的 gMSA 体系结构

主机未加入域的容器的 gMSA 使用可移植的用户标识代替主机标识来检索 gMSA 凭据。 因此，无需再手动地将 Windows 工作器节点加入域。 用户标识在 Kubernetes 中另存为机密。 下图显示了为具有未加入域的主机的容器配置 gMSA 的过程：

组托管服务帐户版本 2 关系图

主机未加入域的容器的 gMSA 提供了一种灵活性，可在不将主机节点加入到域的情况下使用 gMSA 创建容器。 从 Windows Server 2019 开始，支持 ccg.exe，这允许插件机制从 Active Directory 检索 gMSA 凭据。 可以使用该标识启动容器。 有关 ccg.exe 的详细信息，请参阅 ICcgDomainAuthCredentials 接口。

主机未加入域和主机已加入域的容器的 gMSA 比较

最初引入 gMSA 时，它要求容器主机加入域，这使得手动将 Windows 工作器节点加入域时产生了很多开销。 对于未加入域的主机的容器，gMSA 解决了此限制，因此用户现在可以将 gMSA 与未加入域的主机一起使用。 gMSA 的其他改进包括以下功能：

  • 不再要求将 Windows 工作器节点手动加入域中，这曾给产生很大开销。 对于缩放方案，这简化了过程。
  • 在滚动更新场景中，用户不再需要将节点重新加入域。
  • 管理工作器节点计算机帐户来检索 gMSA 服务帐户密码的过程更加简单。
  • 使用 Kubernetes 配置 gMSA 的端到端过程的复杂程度降低。

准备阶段

若要使用组托管服务帐户运行 Windows 容器，需要满足以下先决条件：

  • 一个 Active Directory 域，其中至少有一台运行 Windows Server 2012 或更高版本的域控制器。 使用 gMSA 没有林或域功能级别要求，但只有运行 Windows Server 2012 或更高版本的域控制器才能分发 gMSA 密码。 有关详细信息，请参阅 gMSA 的 Active Directory 要求。
  • 创建 gMSA 帐户所需的权限。 若要创建 gMSA 帐户，您必须是域管理员或使用有权创建 msDS-GroupManagedServiceAccount 对象的帐户。
  • 访问 Internet，下载 PowerShell 模块 CredentialSpec。 如果在无连接的环境中工作，则可先在能够访问 Internet 的计算机上保存此模块，然后将其复制到开发计算机或容器主机。
  • 若要确保 gMSA 和 AD 身份验证正常工作，请确保将 Azure Stack HCI 和 Windows Server 群集节点配置为将其时间与域控制器或其他时间源同步。 还应确保 Hyper-V 配置为将时间同步到任何虚拟机。

在域控制器中准备 gMSA

按照以下步骤在域控制器中准备 gMSA：

  1. 在域控制器中，准备 Active Directory 并创建 gMSA 帐户。

  2. 创建域用户帐户。 此用户帐户/密码凭据保存为 Kubernetes 机密，用于检索 gMSA 密码。

  3. 若要创建 GMSA 帐户并授权读取步骤 2 中创建的 gMSA 帐户的密码，请运行以下 New-ADServiceAccount PowerShell 命令：

     New-ADServiceAccount -Name "<gmsa account name>" -DnsHostName "<gmsa account name>.<domain name>.com" -ServicePrincipalNames "host/<gmsa account name>", "host/<gmsa account name>.<domain name>.com" -PrincipalsAllowedToRetrieveManagedPassword <username you created earlier> 

    对于 -PrincipalsAllowedToRetrieveManagedPassword，请指定前面创建的域用户名，如以下示例所示：

    New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.akshcitest.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.akshcitest.com" -PrincipalsAllowedToRetrieveManagedPassword "testgmsa"

准备 gMSA 凭据规范 JSON 文件

若要准备 gMSA 凭据规范 JSON 文件，请按照创建凭据规范中的步骤操作。

为群集中的 Windows Pod 和容器配置 gMSA

Kubernetes 社区支持对 gMSA 使用已加入域的 Windows 工作器节点。 在 Azure Stack HCI 和 Windows Server 上的 AKS 中，即使不需要域加入 Windows 工作器节点，也还有其他配置步骤。 这些步骤包括安装 Webhook、 (CRD) 的自定义资源定义和凭据规范，以及启用基于角色的访问控制 (RBAC 角色) 。 以下步骤使用旨在简化配置过程的 PowerShell 命令。

在完成以下步骤之前，请确保已安装 AksHci PowerShell 模块并 kubectl 可以连接到群集。

  1. 若要安装 Webhook，请运行以下 Install-AksHciGmsaWebhook PowerShell 命令：

    Install-AksHciGMSAWebhook -Name <cluster name>

    若要验证 Webhook Pod 是否成功运行，请运行以下命令：

    kubectl get pods -n kube-system | findstr gmsa

    你应会看到一个带有 gmsa-webhook 前缀的 Pod 正在运行。

  2. 创建用于存储 Active Directory 用户凭据的机密对象。 完成以下配置数据并将设置保存到名为 secret.yaml 的文件中。

    apiVersion: v1
kind: Secret
metadata:
   name: <secret-name>
   namespace: <secret under namespace other than the default>
type: Opaque
stringData:
   domain: <FQDN of the domain, for example: akshcitest.com>
   username: <domain user who can retrieve the gMSA password>
   password: <password>

    然后，运行以下命令来创建机密对象：

    kubectl apply -f secret.yaml

    注意

    如果在非默认命名空间下创建机密，请记住将部署的命名空间设置为同一命名空间。

  3. 使用 Add-AksHciGMSACredentialSpec PowerShell cmdlet 创建 gMSA CRD， (RBAC) 启用基于角色的访问控制，然后将角色分配给服务帐户以使用特定的 gMSA 凭据规范文件。 这篇关于为 Windows Pod 和容器配置 gMSA 的 Kubernetes 文章详细描述了这些步骤。

    使用 JSON 凭据规范作为以下 PowerShell 命令的输入（带星号 * 的参数是必需的）：

    Add-AksHciGMSACredentialSpec -Name <cluster name>*  
  -credSpecFilePath <path to JSON credspec>* 
  -credSpecName <name for credspec as the k8s GMSACredentialSpec object>* 
  -secretName <name of secret>* 
  -secretNamespace <namespace of secret>  
  -serviceAccount <name of service account to bind to clusterrole>  
  -clusterRoleName <name of clusterrole to use the credspec>*  
  -overwrite

    若要查看示例，请参阅以下代码：

    Add-AksHciGMSACredentialSpec -Name mynewcluster 
  -credSpecFilePath .\credspectest.json 
  -credSpecName credspec-mynewcluster 
  -secretName mysecret 
  -clusterRoleName clusterrole-mynewcluster

部署应用程序

使用以下示例设置创建部署 YAML 文件。 必需的条目包括 serviceAccountName、gmsaCredentialSpecName、volumeMounts 和 dnsconfig。

  1. 添加服务帐户：

    serviceAccountName: default
   securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName:

  2. 添加凭据规范对象：

    securityContext: 
     windowsOptions: 
       gmsaCredentialSpecName: <cred spec name>

  3. 装载部署的机密：

    volumeMounts:
     - name: <volume name>
       mountPath: <vmount path>
       readOnly: true
   volumes:
     - name: <volume name>
       secret:
         secretName: <secret name>
         items:
           - key: username
             path: my-group/my-username

  4. 在 dnsConfig 下添加域控制器的 IP 地址和域名：

    dnsConfig: 
     nameservers:
       - <IP address for domain controller>
     searches: 
       - <domain>

验证容器是否适用于 gMSA

部署容器后，通过以下步骤验证它是否正常工作：

  1. 运行以下命令来获取用于部署的容器 ID：

    kubectl get pods

  2. 打开 PowerShell 并运行以下命令：

    kubectl exec -it <container id> powershell

  3. 进入容器后，运行以下命令：

    Nltest /parentdomain 
Nltest /sc_verify:<domain> 

    Connection Status = 0 0x0 NERR_Success The command completed successfully.

    此输出显示计算机已通过域控制器进行身份验证，并且客户端计算机和域控制器之间存在安全通道。

  4. 检查容器是否可获取有效的 Kerberos 票证授予票证 (TGT)。

    klist get krbtgt

    A ticket to krbtgt has been retrieved successfully

清理群集中的 gMSA 设置

如果需要清理 gMSA 设置，请按以下卸载步骤进行操作。

卸载凭据规范

若要卸载，请运行以下 Remove-AksHcigmsaCredentialSpec PowerShell 命令：

Remove-AksHciGMSACredentialSpec -Name <cluster name> -credSpecName <cred spec object name> -clusterRoleName <clusterrole object name> -serviceAccount <serviceaccount object name> -secretNamespace <namespace of the secret object>

卸载 Webhook

若要卸载 Webhook，请运行以下 Uninstall-AksHciGMSAWebhook PowerShell 命令：

Uninstall-AksHciGMSAWebhook -Name <cluster name>

后续步骤