HashiCorp发布了其秘密管理工具Vault 的1.0版本，并开源了在发生故障或重启后继续使用Vault服务器所需的“自动解封（auto-unseal）”特性。这个版本提供了一种可以用于临时工作负载的新令牌batch。另一个新特性是，Kubernetes auth现在通过projected卷支持服务帐户令牌，以便将令牌注入到pod中。HashiCorp还推出了一个名为Vault Advisor的支持工具，帮助用户在使用Vault时自动去除对某些凭证的不必要访问。

开源以前只在企业版本中提供的自动开封特性是一个呼声很高的需求，Kubernetes专家Kelsey Hightower也呼吁过。自动解封是在集群中发生故障或重启之后使数据解密成为可能的过程。当Vault首次启动时，它是密封的，存储的所有数据都是加密的。要解密数据，你需要首先解封。

自动解封过程可以与使用它作为目标的云提供商集成，这使你可以用不变的方式继续使用Vault。例如，在AWS KMS中，为了使用以前存储的键解封集群，主键会被重新构造。所有主要的云提供商都在支持范围：AWS、Azure、GCP和阿里巴巴。例如，这里有一份Terraform和AWS KMS的指南。

Vault 1.0中另一个重要的新特性是，增加了一种新的令牌类型，称为batch令牌，而过去称为简单令牌的东西现在称为服务令牌。服务令牌支持所有令牌特性，如更新或撤销，并存储在Vault集群中以供跟踪。Batch令牌不需要在磁盘上存储，因此，它们很适合用于短时间的突发工作负载，比如无服务器应用程序。

Vault 1.0还实现了与Kubernetes的更好集成。在pod中运行的应用程序将能够使用Vault管理秘密、加密操作及进行动态访问。例如，你可以使用动态秘密创建一个pod，动态请求一组临时数据库凭据。

HashiCorp还推出了一个名为Vault Advisor的支持工具，它可以指导用户正确地使用Vault，报告Vault配置是否正确，以及应用程序是否正确地使用了它。通过阅读Vault的日志，Advisor实用程序可以发现改进Vault使用的机会。例如，确保用户具有使用其Vault密钥所需的最小权限集。

根据HashiCorp首席技术官Armon Dadgar的说法，1.0意味着主要用例已经明确、稳定，并广泛地部署到了许多企业中，如Adobe、Hulu、Splunk、Equinix等。

GitHub中的一些项目，如vault -init、vault -unsealer和vault -unseal，已经为那些没有使用Vault企业版的用户复制了自动解封特性。但是，现在不再需要这些项目了，因为仅限于企业客户的官方特性已经提供给了整个社区。HashiCorp Vault 1.0可以从HashiCorp的网站上下载。

查看英文原文：HashiCorp Vault 1.0 Open Sources Auto-Unseal, Adds Batch Tokens