在 Ansible 自动化平台 2 中使用适用于 Windows 的 Kerberos

Kerberos 通常是在域环境中管理 Windows 服务器的首选身份验证方法。多年来，红帽 Ansible 自动化平台一直支持客户利用 Kerberos 身份验证。那么，为什么要重提这个话题呢？ 

Ansible 自动化平台 2 于 2021 年 7 月发布，对该平台进行了重大架构调整。其中一项根本性变化是引入了自动化执行环境 ，即使用容器来一致地打包、分发和执行 Ansible Playbook。简而言之，自动化执行环境由 RHEL 基础镜像、Ansible Core 以及执行 Ansible 自动化所需的任何依赖项（通常是 Ansible 内容集和 Python 库）组成。 

向容器迁移意味着我们有时需要将 localhost 视为容器。有一篇出色的博客文章详细介绍了在自动化执行环境中，localhost 并不像看起来那么简单。

了解所有这些信息后，让我们通过一个引导式示例来了解如何在 Ansible 自动化平台 2 中配置 Kerberos 身份验证，如何测试配置，以及如何配置自动化控制器以使用 Kerberos。

配置示例

为了将 Kerberos 与 Ansible 搭配使用，我们需要一个 Kerberos 配置文件。配置文件的内容会因多种因素而异，如 DNS 配置、KDC 发现和域数量。在本例中，我们只有一个域 DEMOLAB.LOCAL，但自动化控制器服务器无法发现该域。

以下是我们的 Kerberos 客户端配置示例。自动化控制器管理指南中记录了一个类似的示例。

 [libdefaults] 
rdns = false 
default_realm = DEMOLAB.LOCAL 

[realms] 
 DEMOLAB.LOCAL = { 
  kdc = ms-ad.demolab.local 
  admin_server = ms-ad.demolab.local 
 } 

现在，我们需要考虑自动化执行环境，并记住 localhost 并不像看起来那么简单！当自动化控制器运行 Ansible Playbook 时，它将调用无权访问控制器节点的底层文件系统的容器镜像。我们需要检查执行环境是否可以访问 Kerberos 客户端配置。有两种方法可以实现这一点。

1. 我们可以从自动化控制器将 Kerberos 客户端配置映射到正在运行的执行环境中。
2. 我们可以使用 Ansible Builder 自定义和构建我们自己的执行环境，并将 krb5.conf 添加到镜像中。

在本例中，我将 Kerberos 客户端配置映射到正在运行的执行环境，因为我不需要进行任何其他更改。 

为了将文件映射到执行环境，我们要将配置写入到自动化控制器服务器上的 Kerberos 客户端配置目录：/etc/krb5.conf.d/DEMOLAB.LOCAL.conf

# cat /etc/krb5.conf.d/DEMOLAB.LOCAL.conf 

[libdefaults] 
rdns = false 
default_realm = DEMOLAB.LOCAL 

[realms] 
 DEMOLAB.LOCAL = { 
  kdc = ms-ad.demolab.local 
  admin_server = ms-ad.demolab.local 
 }   

从命令行进行测试

我们已准备好从命令行检查配置。首先，我们来确认一下可用于测试的执行环境。在自动化控制器服务器上，我们可以切换到 awx 用户并列出执行环境镜像。在这里，我们可以看到 ee-supported-rhel8 执行环境可用，这正是我想要用于测试的镜像。

 $ su - awx 
$ podman images 
REPOSITORY                                                         TAG     IMAGE ID   CREATED   SIZE 
registry.redhat.io/ansible-automation-platform-23/ee-supported-rhel8  latest   024856bccc5f  4 weeks ago  1.66 GB 

如果您需要使用其他镜像进行测试，可使用“podman pull”从容器注册表复制相关镜像。

现在，我们来看看能否将配置目录映射到执行环境中，进行身份验证并获取 kerberos 工单。以下 Podman 命令将启动我们的执行环境容器，并将 /etc/krb5.conf.d/ 映射到正在运行的容器。我们还将在容器内获得一个交互式 shell，以便测试 kinit。最后一点要注意的是，Kerberos 使用凭据缓存来保存有效的 Kerberos 凭据。再次提醒，localhost 并不像此处显示的那样，因此我们无法访问文件系统和 Kerberos 缓存。我们将创建一个临时 Kerberos 凭据缓存，以便通过设置 KRB5CCNAME 变量来测试配置。winrm 连接插件使用类似的机制。 

 $ podman run --rm  -v "/etc/krb5.conf.d:/etc/krb5.conf.d:O" -it registry.redhat.io/ansible-automation-platform-23/ee-supported-rhel8:latest /bin/bash 

bash-4.4# export KRB5CCNAME=`mktemp` 
bash-4.4# echo $KRB5CCNAME 
/tmp/tmp.ZzBXbtGiV1 
bash-4.4# kinit svc-ansible@DEMOLAB.LOCAL 
Password for svc-ansible@DEMOLAB.LOCAL: 
bash-4.4# klist 
Ticket cache: FILE:/tmp/tmp.ZzBXbtGiV1 
Default principal: svc-ansible@DEMOLAB.LOCAL 

Valid starting Expires         Service principal 
04/04/23 14:01:37  04/05/23 00:01:37  krbtgt/DEMOLAB.LOCAL@DEMOLAB.LOCAL 
    renew until 04/11/23 14:01:33

作为进一步测试，我们可以验证工单是否适用于对特定服务器进行身份验证。在执行环境中成功运行 kinit 后，我们可以使用 kvno 向目标主机进行身份验证。在本例中，我们要检查是否可以使用工单对 windows2.demolab.local 进行身份验证。

 bash-4.4# kvno http/windows2.demolab.local 
http/windows2.demolab.local@DEMOLAB.LOCAL: kvno = 1 
bash-4.4# klist 
Ticket cache: FILE:/tmp/tmp.pe2PBReLm5 
Default principal: svc-ansible@DEMOLAB.LOCAL 

Valid starting Expires         Service principal 
05/10/23 15:26:35  05/11/23 01:26:35  krbtgt/DEMOLAB.LOCAL@DEMOLAB.LOCAL 
    renew until 05/17/23 15:26:33 
05/10/23 15:26:49  05/11/23 01:26:35  http/windows2.demolab.local@DEMOLAB.LOCAL 
    renew until 05/17/23 15:26:3 

测试结果不错！是时候将配置移入自动化控制器了！ 

配置自动化控制器

我们需要在自动化控制器中为我们的 Windows 帐户添加 Machine 凭据。这应当是用户主体名称（UPN），格式为“username@DOMAIN.COM”。若要在自动化控制器中添加凭据，请前往左侧菜单中的 Credentials ，按下 Add ，然后选择 Machine 作为凭据类型。输入域用户和密码，如下所示：

接下来，我们可以将 Kerberos 客户端配置映射到执行环境。管理员需要配置 Settings -> Job Settings  ，然后编辑“path to expose to isolated jobs”，添加 Kerberos 目录。请注意，这与我们通过 CLI 进行测试时使用的格式相同。新配置应如下所示：

是时候进行测试了！我们可以使用简单的“ping”playbook 来验证配置。我们还可以增加日志记录，以包含 WinRM 连接消息。编辑作业模板，并将详细程度设置为级别 5。

启动作业模板后，我们应该会看到详细的连接消息。

我们可以看到，临时 Kerberos 凭据缓存已创建，帐户能够进行身份验证，并且我们获得了一张工单。该 playbook 应当会成功完成。

故障排除

在执行环境中配置 Kerberos 时，您可能会遇到一些错误消息。以下是您可能会看到的一些错误以及可能的解决方案。

• 初始化 Kerberos 5 库时无法读取包含的配置文件目录 - 这可能表明 /etc/krb5.conf.d 目录中的有一个配置文件试图包含执行环境无法访问的其他目录。检查 /etc/krb5.conf.d 中可能包含 includeir 选项的任何配置文件。
• 获取默认 ccache 时，持久密钥环名称中的 UID 无效 - 记得按上文所述设置临时凭据缓存目录。
• 在获取初始凭证时，无法找到“<DOMAIN>”域的 KDC - 导致此错误的原因可能有很多。检查 Kerberos 配置是否正确，并且配置中是否列出了有效的 KDC。如果您依靠 DNS 来查找 KDC，请确保 dns_lookup_kdc 设置为 true。 
• 在 Kerberos 数据库中未找到服务器 - 这通常与 DNS 问题或 Ansible 清单配置不正确有关。检查清单中的主机名称是否与 DNS 中的服务器名称匹配。此外，使用 WinRM 调试日志验证 Ansible 是否正在尝试使用 FQDN 连接主机。在以下示例中，为 Windows 服务器设置了 ansible_host 变量，并且我们尝试使用 IP 地址而非主机名进行连接。

后续步骤

希望此示例有助于您了解 Ansible 自动化平台 2 中的一些更改，以及如何开始使用 Kerberos 身份验证来管理 Windows 服务器。Windows 仍然是 Ansible 的首要支持平台，还有更多资源可在您的旅程中为您提供帮助。

• 适用于 Windows 的 Ansible - 了解如何使用 Ansible 来管理 Windows 基础架构和常见用例。
• 试用订阅 - 您准备好了吗？获取您自己的试用订阅，无限制地访问 Ansible 自动化平台的所有组件。