实现容器化 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 命令行实用工具和 join 开关，从而执行域联接。

此过程的其余部分与任何包含 Windows Server 工作器节点的 Kubernetes 群集相同，它的简要步骤如下：

  1. 在 AD DS 中预配 gMSA，并将它分配到 Windows Server 节点。
  2. 定义表示 AD DS gMSA 的自定义 Kubernetes 资源类型 (GMSACredentialSpec)。
  3. 配置一种基于 Webhook 的机制，以自动填充和验证 Pod 和容器的 GMSACredentialSpec 引用。
  4. 根据 GMSACredentialSpec 资源类型创建自定义资源。
  5. 定义群集角色，以为 GMSACredentialSpec 资源启用 RBAC。
  6. 将角色分配给 AD DS gMSA，以便授权其使用相应的 GMSACredentialSpec 资源。
  7. 在将用于 AD DS 身份验证的 Pod 定义中包括对 GMSACredentialSpec 资源的引用。

备注

若要启用 gMSA 支持，Kubernetes 群集名称的长度不得超过 3 个字符。 此约束源于已建立域联接的计算机名的字符数上限（即 15 个）。

知识检查

1.

Contoso 的信息安全团队要求你研究选项来对 Azure Stack HCI 上的 AKS 托管的基于 Windows 的容器化工作负载实现基于 AD DS 的身份验证。 首先，将包含 Windows Server 节点的 Kubernetes 群集部署到 Azure Stack HCI 群集中。 下一步该怎么办？