在SaltStack中安全地获取Minion ID

48次阅读

问题描述

在使用SaltStack时，用户在pillar top.sls文件中找到了一个目标为example的SLS文件，其中包含了一个用于目标主机的pillar配置。然而，用户发现这种做法可能存在安全隐患，因为它违反了SaltStack的最佳实践之一：不要在pillar top文件中使用grains来匹配任何敏感的pillar配置。虽然这种做法看起来很方便，但是grains是在Minion上进行评估的，所以如果Minion受到足够的攻击，它可以返回任何攻击者希望得到的任意grain数据。这就可能导致Minion声称自己是SSL（或VPN！）终止者，以获取私钥等敏感数据。

尽管存在这种安全风险，但是有一个理论上的解决方案，那就是使用Minion ID。Minion ID是唯一的，并且在主节点上进行了加密验证。但是问题在于，用户无法找到一种方式来在Jinja模板中获取Minion ID，而又不依赖于grains，因为grains是在Minion上执行的，即使Salt主节点在传输层面知道Minion ID，但是通过grains查询Minion ID实际上是在向Minion请求ID，而不是主节点提供的ID。

所以，用户希望知道如何在主节点的Jinja模板中获取主节点的Minion ID。

解决方案

请注意以下操作可能受版本差异影响，请在执行之前确保备份重要数据。

使用Minion ID获取Minion ID

目前有一种安全的方法可以实现这一目标，即使用{{opts.id}}来显式地获取Minion ID。opts实际上是一个Salt的内部数据结构，用于存储配置和上下文信息，虽然没有正式的规范进行说明，但在一个bug评论中指出了它可以用于这个目的。

在Salt的下一个版本中（版本号晚于2016.11.5），id grain会被特殊处理，使得可以安全地使用{{grains.id}}来获取Minion ID。

示例代码

以下是在SaltStack中如何使用Jinja模板获取Minion ID的示例代码：

# 在pillar top.sls文件中
example:
  - match: grain
  - hostspecificsls

# 在hostspecificsls文件中
{% set minion_id = opts.id %}

在上面的示例中，我们在pillar配置中使用了一个名为example的目标，使用grain匹配，并引用了hostspecificsls文件。在hostspecificsls文件中，我们使用了{% set minion_id = opts.id %}来获取Minion ID并存储在一个变量中。

通过这种方式，我们可以在主节点的Jinja模板中安全地获取Minion ID，而不依赖于grains，从而避免了安全隐患。