保留入站链接只是为了避免打破历史记录。这里讨论的范例已经被扩展、形式化并标准化为一个称为响应包装的内置保险库功能。查看响应包装概念页面以了解更多信息。上次更新时间：2016-04-27在vault0.3发布的文章中，介绍了cubbyhole后端，并提供了一个示例工作流，演示了如何使用它对Vault进行安全身份验证。在HashiCorp，我们相信基于Cubbyhole的身份验证是在各种各样的用例中对保险库进行身份验证的最佳方法。在这篇文章中，我们将解释为什么Cubbyhole可能是适合您的身份验证模型，并介绍关于Cubbyhole身份验证的多个注意事项，以帮助适应许多实际的部署场景。这篇文章将首先解释开发Cubbyhole身份验证模型的动机，然后描述模型本身，最后介绍设计部署场景的一些考虑因素。请注意：Cubbyhole身份验证提供了一组有用的安全原语。本帖中的信息旨在提供有用的信息，但并非详尽无遗，不应被视为一种或另一种方法的建议。由实现者来确保任何给定的身份验证工作流符合其组织的策略。»为什么是小房间？在Vault中，有两种主要的身份验证后端可用：面向用户的身份验证后端：这些后端通常依赖于共享机密的知识，例如userpass和ldap的密码或GitHub的GitHub API令牌。这种共享的知识是在带外分发的。面向机器的身份验证后端：这些后端依赖于客户端的某些固有属性（例如app id的MAC地址）或带外分发的秘密（例如证书的TLS私钥/证书），以便促进机器和应用程序的自动身份验证。面向用户的后端相当简单且易于理解，因为它们映射到许多其他系统使用的身份验证范例。但是，面向机器的身份验证在任何情况下都更为困难，Vault也不例外：一台机器的许多内在属性都可以被其他机器发现。例如，appid后端依赖于一台知道自身某些独特属性的机器作为共享机密之一。给出的建议是使用一台机器的MAC地址作为一个唯一的机器属性，或者将其作为一个散列。没有salt哈希，MAC地址就可以被子网中的任何其他机器发现。如果您使用的是salted散列，那么您需要一种安全的方法来将共享的salt值分发到机器，将您置于带外秘密分发场景中（见下文）。选择其他计算机无法发现的值通常意味着填充app id的进程也不容易发现该值，这再次导致带外秘密分发问题。带外分发依赖于到机器的安全通道。如果存在这样一个安全通道，例如分发证书的私钥以允许客户端使用证书身份验证，那么它也可以用于分发保险库令牌。如果要使用Vault本身来建立安全通道，例如使用pki后端颁发客户机/服务器TLS证书以实现进一步的安全通信，还存在其他复杂问题。这两种秘密都容易受到操作员的窥探。例如，再次以app id为例：一台机器的MAC地址（一种固有属性）几乎可以肯定地为操作员所知。appid身份验证的另一半是机器的唯一UUID（带外分布式机密），建议存储在配置管理中。然而，在配置管理中存储此值通常意味着它以明文形式存储在磁盘上（如果使用DVCS来修改配置管理信息，很可能在很多地方，这是非常常见的）。即使它是在磁盘上加密的（大多数配置管理实用程序都能做到），任何用于部署到计算机上的操作员或服务都必须知道解密密钥，而解密密钥本身就是一个秘密，现在必须加以保护和安全地分发。自动秘密分发没有完美的答案，这反过来又意味着自动机器认证没有完美的答案。然而，风险和暴露可以最小化，成功使用窃取的秘密的难度可以提高。使用cubbyhole后端和一些Vault的高级令牌属性可以使身份验证模型在许多情况下比Vault中的其他方法更安全，并且与其他系统相比也更安全。这反过来又增强了Vault作为访问控制系统对存储在Vault本身和其他系统（如MySQL、PostgreSQL或Cassandra）中的机密的访问控制系统的实用性，甚至可用于直接访问其他系统（例如，通过SSH或TLS证书）。»小房间认证模型作为一个快速更新，cubbyhole后端是一个简单的文件系统抽象，类似于通用后端（默认情况下在secret/）上安装，但有一个重要的转折点：整个文件系统的作用域仅限于一个令牌，而任何其他令牌都无法访问整个文件系统。由于许多用户正在使用保险库机密来建立到其他计算机的安全通道，因此我们希望开发一种本身不依赖于安全通道（但当然可以通过安全通道增强）的身份验证模型。相反，该模型利用了Vault令牌和Cubbyhole后端提供的一些安全原语：有限用途：令牌只能对特定数量的操作有效有限持续时间：令牌可以在可配置的持续时间后被吊销有限访问：只有一个令牌可用于设置或检索其文件柜中的值使用这些原语，并结合来自该领域和几家商业公司的安全专家的输入和反馈，我们构建了一个新的认证模型。像所有的身份验证模型一样，它不能保证完美的安全性，但它具有一些理想的属性。该模型的工作原理如下，假设我们正在尝试将保险库令牌获取到应用程序（可以是计算机、容器或虚拟机，而不是）：负责创建保险库身份验证令牌的进程将创建两个令牌：永久（perm）令牌和临时（temp）令牌。perm令牌包含容器中应用程序所需的最后一组策略。临时令牌的租约期限很短（例如15秒），最大使用计数为2。temp令牌用于将perm令牌写入特定于temp的cubbyhole存储器。这需要一个写操作，将temp的剩余使用减少到一个。被调用的进程将temp令牌提供给应用程序管理引擎（例如，Docker），后者启动应用程序并将temp令牌值注入应用程序环境。应用程序从环境中读取temp令牌并使用它从杂物箱获取perm令牌。此读取操作耗尽了temp令牌的使用限制，temp令牌将被吊销，其存储空间将被销毁。让我们看看这个方法的一些属性：即使temp令牌的值以明文形式传递给进程，perm令牌的值也将是（应该是！）由TLS覆盖。temp令牌的值在它过期或被吊销之后是无用的，并且在目标应用程序的内存之外，perm令牌的值将永远丢失，因为temp令牌的存储空间被破坏。因此：写入磁盘以将其传递给应用程序的临时令牌不会造成长期安全威胁。如果记录了该值（例如，因为它是在其环境变量设置中传递给容器的），则日志中的值不会造成长期安全威胁。坏角色的访问是可以检测到的，因为应用程序将无法使用temp令牌获取perm令牌，此时它可以发出警报。因为对储藏室的访问记录在保险库的审计日志中，然后，操作员可以使用审计日志来发现一个应用程序启动的时间是否太长（在撤销之前，只有一个正在被访问的cubbyhole的实例会出现在审计日志中），或者另一个进程是否使用该令牌（两个实例将出现在审计日志中）来窃取perm令牌。当然，根据具体的设置，仍然存在渎职的可能性，但也有一些缓解措施：如果临时令牌通过不安全的通道泄漏给应用程序，则可能会受到嗅探。下一节中详细介绍的一些考虑因素提供了对此的防御。如果嗅探器实际获取了perm令牌的值，这是可以检测到的。如果操作员或另一台计算机能够在temp令牌值仍然有效的情况下截获它（例如，通过在启动后立即读取应用程序的环境，或者如果包含环境的日志在temp令牌的生存时间内可用），则他们可以使用该值来检索perm令牌的值。这也是可以检测到的。没有一种认证机制是完美的。然而，有限的使用、有限的持续时间和有限的访问共同构成了一组强大的安全原语。检测坏角色访问的能力也是一个非常重要的特性。通过将它们结合起来，Cubbyhole身份验证模型提供了一种对保险库进行身份验证的方法，这种方法很可能满足最严格的安全部门的需要。»杂物箱验证注意事项此时一个自然的问题是"谁或什么人负责创建temp和perm令牌？"由于此身份验证工作流只是一个模型，因此没有单一的结构化方式来使用它。然而，另一方面是，有很多灵活性可以轻松地制定出符合要求的解决方案