我们很荣幸地宣布Vault 0.3的发布。保险库是管理机密的工具。从存储凭证和API密钥到加密敏感数据，Vault旨在满足所有机密管理需要。Vault 0.3带来了许多新功能，包括ssh后端、cubbyhole后端、传输后端的新功能和改进、可设置的全局和每次装载的default/max TTLs、解封密钥的PGP加密、通用后端的大性能改进、Duo Multi-Factor身份验证支持等等。我们不可能在这里列出所有的改进，因此请查看完整的Vault 0.3更改日志以了解更多详细信息。此外，整个0.2代码库都接受了著名安全专家iSEC合作伙伴的审计。虽然我们不能分享结果，但他们的反馈是有价值的，我们打算继续定期进行安全审计，以确保即使是最谨慎的组织也能信任保险库的秘密。像往常一样，感谢我们的社区，感谢他们的想法、错误报告和拉取请求。您可以从project 3网站下载。继续阅读以了解有关Vault 0.3中主要新功能的更多信息。阅读更多»SSH后端新的vaultssh secret后端允许Vault通过使用一次性密码（otp）或动态生成的ssh密钥将ssh仲裁给计算机。在一个典型的组织中，SSH访问的委派有很多种方式。最不安全的是手动将访问令牌（密码或密钥）共享给目标主机上的特定用户；一旦这样做了，就很难或不可能知道哪个实际的用户使用该用户帐户执行了操作。一个进步是在每台机器上为每个用户创建单独的用户帐户，这样可以更好地跟踪，但在后勤上却是一场噩梦。第三种方法是代理SSH访问的bastion主机，允许集中配置，但会严重影响性能。Vault的ssh后端通过将Vault的灵活策略/ACL功能与灵活的角色定义结合起来解决了此问题，允许经过身份验证的Vault用户从Vault请求凭据作为中心配置点，然后直接连接到终端主机，而不会造成性能损失。角色将用户名和其他参数与CIDR包含和排除列表相匹配。以下示例使用建议的后端一次性密码类型。因为每次访问都有不同的一次性密码，所以Vault的审核日志可以精确地将用于登录系统的令牌结合起来，即使这些登录名访问的是同一个用户。$vault write ssh/roles/otp_key_role key_type=otp default_user=用户名cidr_list=x.x.x.x/y，m.m.m.m/n成功！数据写入：ssh/roles/otp_key_role$vault write ssh/creds/otp_key_角色ip=x.x.x.x键值租赁_id ssh/creds/otp_key_角色/73bbf513-9606-4bec-816c-5a2f009765a5租期600租赁可续约假端口22用户名用户名ip x.x.x.x图例2f7e25a2-24c9-4b7b-0d35-27d5e5203a5c密钥类型otpOTP可以直接用作SSH密码：$宋承宪用户名@localhost密码：用户名@ip:~$或者，您可以使用新的vault ssh命令将其自动化：$vault ssh-角色otp_key_角色用户名@x.x.x.x用户名@ip:~$SSH后端是除了存储秘密数据之外，如何将VaUT用作安全基础的另一个例子。使用ssh后端可以简化组织迁移到零信任数据中心的过程。»杂物箱后端新的Vault cubbyhole secret后端是通用secret后端的一个变体，它有一个重要区别：整个空间被绑定到一个特定的令牌上，给每个令牌一个用于存储数据的"cubbyhole"。当令牌过期或被吊销时，它的存储空间将被删除，其中的数据将不再可访问。这将支持许多有用的工作流，包括一些以前比较困难的身份验证场景。作为一个例子，假设您需要给一个容器一个保险库令牌，它将使用它来获取它的其余机密和凭证。一种常见的方法是将令牌注入容器的环境中，缺点是该环境可由任何在容器运行时中可见的进程读取，并且很可能出现在容器管理系统、主机或容器本身的日志中。但是，在许多情况下，这些日志可能无法立即访问。因此，使用cubbyhole后端，我们可以利用Vault的几个安全原语（有限使用凭据、凭据过期）来构建以下身份验证工作流：负责创建保险库身份验证令牌的进程将创建两个令牌：永久（perm）令牌和临时（temp）令牌。perm令牌包含容器中应用程序所需的最后一组策略。临时令牌的租约持续时间为15秒，最大使用计数为2。temp令牌用于将perm令牌写入特定于temp的cubbyhole存储器。这需要一个写操作，将temp的剩余使用减少到一个。被调用的进程将temp令牌提供给容器管理引擎，后者启动容器并将temp令牌值注入容器环境。容器中的应用程序从容器环境中读取temp令牌，并使用它从杂物箱获取perm令牌。此读取操作耗尽了temp令牌的使用限制，temp令牌将被吊销，其存储空间将被销毁。如果应用程序无法使用temp令牌，它会发出警报；因为对文件柜的访问记录在Vault的审核日志中，因此操作员可以使用这些日志来发现应用程序启动时间是否过长（并相应地调整临时令牌的超时时间），或者是否有其他进程使用了该令牌。对于初始凭证管理的鸡和蛋问题，没有任何解决方案是完美的。但是，由于无效期很短，而且共享初始凭证的使用有限，我们认为对于许多试图管理安全策略的团队来说，这是一个可以接受的解决方案。»灵活的TTLVault现在支持可调的系统和每次装载的TTL，用于默认和最长持续时间。系统设置在Vault的配置文件中配置。每个装载配置由一个新命令处理：mount tune，以及mounts命令的附加输出：$vault坐骑路径类型默认TTL Max TTL Description每个令牌私人秘密存储不适用机密/通用系统系统通用机密存储用于控制、策略和调试的系统终结点$vault mount tune-默认租约ttl=4h-max lease ttl=24h secret成功调谐"秘密"坐骑！$vault坐骑路径类型默认TTL Max TTL Description每个令牌私人秘密存储不适用机密/通用14400 86400通用密钥存储用于控制、策略和调试的系统终结点此功能的一个重要部分是，虽然每次装载的默认TTL必须小于每次装载的最大TTL（或者，如果没有每次装载的最大TTL，则为系统最大TTL），但是每次装载的最大TTL覆盖系统值（例如，需要根令牌或具有适当sudo访问权限的令牌）。再加上大多数后端都可以安装在多个路径上，这使得管理灵活性非常高。有关详细信息，请参阅mounts API文档。注意：目前取决于每个后端是否遵循设置的默认值。一些后端可能会忽略这一点，例如允许每个角色使用默认值。但是，配置的最大值是由Vault的核心强制执行的，因此将始终遵守。»用于解封密钥的PGP加密现在可以在初始化Vault或旋转其主密钥时传递pgp_keys参数，该主密钥被格式化为带有base64编码的pgp密钥的字符串数组。长度必须与secret\u shares参数匹配。如果提供，每个输出解封密钥都将使用给定的公钥进行加密；顺序将被保留。有关更多详细信息，请参阅init API文档。»通用的性能改进通用后端支持TTL的思想，但在TTL用完时并不实际销毁数据。这个想法是让数据的编写者告诉数据的消费者他们应该多久检查一次新值。但是，每次读取带有TTL的值集都会生成一个租约，当读取数量增加时，这将成为一个非常昂贵的操作。在0.3中，泛型在读取值时不再生成租约。TTL仍将返回；系统/装载默认值，或在特定密钥上设置的TTL，但此操作不会在Vault的核心中注册租约。基准测试结果显示，Vault可以支持的每个时间段的读取次数增加了大约10倍。»双重多因素认证支持为了支持auth后端（目前是ldap和userpass），Vault的mfa auth支持现在可以使用Duo。有关详细信息，请参阅mfa文档。»升级详细信息Vault 0.3对存储数据的方式进行了一些更改，旨在进一步增强Vault在其物理存储中检测篡改的能力。因此，早期版本的Vault无法读取Vault 0.3写入的所有数据。如果您认为您可能需要回滚，请确保您有存储后端数据的副本。还有一些其他的不推荐；请注意，不推荐和重大更改已提前在Vault邮件列表中宣布：正如Vault 0.3更改日志中所述，不再支持cookie身份验证。必须使用X-Vault-Token头进行身份验证。为了解决"租赁"一词的混淆，人们用"租赁"来描述一个集合的集合