我已经开始和Hashicorp的Vault一起玩管理秘密，并且对Vault密封的日常问题有一些疑问。我的工作流程有两个auth后端;特定用户访问具有写入访问权限的Vault以添加新的秘密，服务器只需访问他们所需的秘密即可。HashiCorp Vault密封问题
1）通常情况下，Vault是否处于非密封状态？我相信它会作为一个动态配置服务器不应该协调一个unseal。
2）密封板外人员是否需要旋转钥匙以防万一入侵？
3）确保Vault过程始终处于运行状态的最佳做法是什么，因为如果它死了，Vault将密封？此外，在高可用性配置中，如果一个Vault节点的进程死亡，是否会为每个人密封Vault？
我问这个问题对谷歌库集团和这是最好的回应：
1) Under normal circumstances, does the Vault stay in an unsealed state? I believe it would as a dynamically provisioned server should not have to coordinate an unseal.
是。一旦Vault被初始化并且被解除密封，它通常处于未密封状态。
2) Is the purpose of sealing to off-board staff to rotate keys and in case of an intrusion?
跳马的密封使交钥匙机制来停止所有的服务库的 。这将需要特定数量的开封密钥持有者到 才能使保险库再次运作。
3) What's the best practice for ensuring the vault process is always running, since if it dies the Vault will seal? Also, in a highly available configuration, if one Vault node's process dies, does it seal the Vault for everyone?
有这个没有官方的最佳实践建议。但 在专用实例/群集中运行保险柜，其中 的内存受限/无法访问。使用 后端以HA模式运行Vault是很好的。如果任何集群节点进入 关闭或者Vault进程重新启动，它将处于密封的 状态，并且需要执行非密封操作才能使其运行 。
最好的， Vishal
从https://www.vaultproject.io/docs/concepts/seal.html摘自：
当Vault服务器启动时，它将以密封状态启动。在这种状态下，Vault被配置为知道在哪里以及如何访问物理存储，但不知道如何解密它。
启封是构造主密钥的过程，需要 读取解密密钥来解密数据，从而允许访问保险柜。
开封之前，Vault几乎不可能进行任何操作。对于 示例验证，管理安装表等等都是不可能的。唯一可能的操作是开启Vault并检查开封的状态。
这样，如果有检测到入侵时，Vault数据可以被锁定
迅速尽量减少损失。如果不访问主密钥碎片，则无法再访问它。