我们很荣幸地宣布Vault 0.6.2的发布。保险库是管理机密的工具。从API密钥和加密敏感数据到成为一个完整的内部CA，Vault旨在满足所有机密管理需要。这篇博文涵盖了两个版本：0.6.1和0.6.2，这两个版本共同构成了一个主要的功能版本，以及大量的额外改进和bug修复。具体内容：批准身份验证后端传输中的收敛加密请求转发和重试其他响应包装终结点简而言之：pki中的密钥使用控制和链式中间支持ldap中的灵活过滤器MongoDB Secret后端Circonus度量集成/sys终结点和列表操作的响应包装有关详细信息，请参阅完整的Vault 0.6.2更改日志。另外，请务必阅读本文末尾的升级信息。像往常一样，感谢我们的社区，感谢他们的想法、错误报告和拉取请求。继续阅读以了解有关Vault 0.6.1/0.6.2中主要新功能的更多信息。»批准身份验证后端AppRole身份验证后端是App ID的继承者（并不推荐），它提供与App ID相同的工作流，同时还添加了大量额外的功能和大大增强的安全性。应用程序ID后端旨在提供一种方法，允许使用两个独立的标识因子（应用程序ID和用户ID）对Vault进行身份验证。带外受信任进程将创建这些值，并将它们推入Vault，然后将它们独立推送到客户端。这里的机制取决于具体的设置。举个例子，一个因子可以被烘焙到一个特定的AMI中；另一个因子可以通过Chef或Puppet传递给特定的主机。在这一过程中的每个阶段，一半的标识因子可能对传输机制可见，但这两个因素加在一起只对生成服务和客户端可见。这种方法有一些问题。一个是构建一个可信的第三方服务来进行协调；理想情况下，Vault应该完成将一个标识符映射到另一个标识符的协调角色。另一个是将这两个因素完全保密，除了可信服务和客户机之外；这通常是相当具有挑战性的。AppRole后端是从头开始构建的，以利用Vault当前的功能集。它支持列表、条目过期和定期颁发令牌。最重要的是，虽然它保留了通过手动指定角色ID和secret ID来使用appid工作流（在AppRole中称为"推"模型）的能力，但它也引入了"拉"模型。在Pull模型中，Vault不是创建凭证并将其推入Vault的第三方服务，而是凭证的真实来源。每个角色都有一个角色ID，有权读取此角色ID ACL'd。每个角色也有自己的一组机密ID。授权用户可以对角色进行调用以生成并返回一个秘密ID，当与角色ID结合时，该秘密ID将用于向保险库验证调用者的身份。重要的是，获取角色ID和secret ID的调用可以利用响应包装在传输过程中对它们进行保护，并保证生成的机密只被目标客户机看到；甚至生成端点的调用者也无法看到它。此外，映射是在内部生成的，其生命周期由Vault控制。Vault可以在秘密id超过有效期后清理它们，并且可以使用访问器列出和撤销它们，类似于令牌访问器。最终的结果是一个比appid更安全、更灵活、更易于管理的面向机器的认证后端，我们认为它是一个非常值得继承的产品。»传输中的收敛加密Transit Secret后端已获得对聚合加密的支持。通常，使用当前提供的加密模式（AES-GCM），每个加密操作都使用一个唯一的nonce，使用相同明文的多个加密操作将产生不同的密文。这是AES-GCM通常推荐的操作模式，因为如果同一个nonce用于多个加密操作，则生成的密文可用于导出有关密钥的信息，并且所有以前和将来的密文值现在都有被泄露的风险。然而，有时当输入相同的明文时，希望有相同的密文输出：收敛加密。一个真实的例子就是能够搜索加密数据。假设您有要加密的客户信用卡交易数据，但仍然希望它是可搜索的。为了尽可能减少可以访问未加密数据的实体数，可能的工作流如下所示：客户信用卡交易到达时包含信用卡号码（以及其他信息，如交易ID）入口服务器有权用密钥K加密数据并加密信用卡号码入口服务器将这些信息放入一个搜索服务（例如Elasticsearch），该服务使用加密的信用卡号码值进行索引现在，您拥有一个数据库，其中包含加密的信用卡信息。现在，假设您要查找给定信用卡号的所有交易：应用服务器接收来自客户的请求，以查找使用其卡进行的所有交易应用服务器有权使用密钥K加密和解密，并查找客户信用卡号码的加密值应用服务器使用加密的信用卡号启动搜索应用服务器将结果返回给客户机，而信用卡号永远不会以明文形式持久地存储传输过程中的收敛加密使此工作流成为可能，同时由于它使用了传输后端的密钥导出模式，并基于上下文和明文生成AES-GCM nonce。»请求转发和重试自成立以来，Vault将向群集中的备用节点发出请求的客户端重定向到活动节点。虽然概念上很简单，但也有一些缺点，尤其是在前面使用负载平衡器时。在最佳情况下，负载平衡器可能会在等待新活动节点的配置更新时失败请求。对于某些负载平衡器，发生这种情况的最小速度是10秒，即使新的活动节点在9秒之前准备就绪，而其他备用节点在整个时间内都知道活动状态的变化。为了帮助解决这种情况，Vault现在在CLI和Go API中包含请求重试。遇到5xx状态代码的请求将重试默认值3次（可配置）。然而，在非常病态的场景中，负载平衡器可以检测到活动节点已关闭，并开始向备用节点发送请求，备用节点将转发回负载平衡器，负载平衡器将请求发送回备用节点，依此类推。另一个常见的问题是通过curl发出的请求。许多用户没有意识到curl需要使用-L标志来跟踪重定向，当他们看到"空白数据"被返回时会感到困惑。Vault现在包含请求转发功能。启用（默认设置）时，保险存储备用节点将向活动节点转发请求，并将响应返回给调用的客户端。更多信息请参见HA概念页面。但是，简而言之：当一个活动节点接管任务时，它会创建一个私钥和自签名证书，并通过加密屏障将其播发到备用节点（因此，与客户端重定向一样，只有未密封的备用节点才能实际转发请求，因为它们必须解封才能读取播发）。备用节点使用此信息在它们和活动节点之间创建一个相互验证的TLS连接。一旦建立了这个连接，就可以序列化客户机请求，将其发送到活动节点进行处理，然后返回给调用方。请求转发在0.6.2中默认启用（但可以全局禁用或按客户端请求禁用）。»响应包装终结点响应包装是在vault0.6中引入的，它提供了一种生成安全工作流的机制。在0.6.2中，添加了几个新的API端点来增强此功能：sys/wrapping/lookup：此端点允许您发现响应包装令牌的TTL和创建时间。它包含在默认策略中。sys/wrapping/wrapp：此端点允许您将任意数据包装在响应包装的令牌中，从而允许您轻松地使用响应包装来安全（或至少，防篡改）传输任意数据。它包含在默认策略中。sys/wrapping/unwrapp：此端点展开响应包装令牌，但与直接读取cubbyhole/response相比有几个好处：它验证令牌是否实际上是一个包装令牌的响应，消除了欺骗途径；它返回原始包装的响应作为其响应，而不是返回必须返回的JSON字符串已解析。这是官方goapi使用的新的解包方法，将来它将是唯一允许的方法。这包含在默认策略中。sys/wrapping/rewrap：这允许重新包装响应包装的令牌，方法是使用原始令牌的TTL将包装好的响应写入一个新的令牌中，而不会泄露包装的内容。这些新的端点提供了功能强大的原语，可用于在响应包装的基础上构建安全工作流。»其他特性此版本中有太多的新功能和改进，无法对所有这些功能和改进进行深入描述，因此下面将简要介绍更多功能和改进：pki中的密钥使用控制和链接的中间层：一组默认的密钥使用现在被放置在已颁发的证书上，但是，该组在角色级别上是完全可控制的。这增加了与严格遵守RFC的程序（如OpenVPN）的兼容性。另外，在设置外部属性时