封印与解封

当 Vault 服务启动时,默认处于封印状态。在该状态下,Vault 知道如何访问物理存储,但无法解密任何存储的数据。

解封时获取 Master Key 明文的过程,通过 Master Key 可以读取并解密存储的数据。

在未解封时,Vault 几乎无法执行任何操作。比方身份认证、管理挂载表等等,都无法执行。唯一可以执行的操作就是解封并检查封印状态。

为什么?

Vault 存储的数据时加密的。Vault 需要加密密钥来解密数据。加密密钥与密文数据被一同存储,但加密密钥本身通过 Master Key 加密。

所以,要解密数据,Vault 必须首先使用 Master Key 解密这个加密密钥。解封就是获取 Master Key 的操作流程。Master Key 与其他 Vault 数据被存放在一起,但使用另一种机制进行加密:解封密钥。

总而言之,绝大多数 Vault 数据用加密密钥加密;加密密钥用 Master Key 加密;Master Key 用解封密钥加密。

Shamir 封印

使用 Shamir 算法解封的过程
图 1.3.2/1 - 使用 Shamir 算法解封的过程

Vault 默认使用 Shamir 算法封印。解封密钥并不是一条单一的密钥,而是使用 Shamir 机密分享算法 将之分割成多个分片。要重建解封密钥,需要特定条分片,然后可以解密 Master Key。

解封

解封通常是通过运行 vault operator unseal 或是调用 HTTP API 完成的。该过程是有状态的:每一条解封 Key 可以被从不同的电脑上以不同的机制输入。这允许构成 Master Key 的分片被保管在不同的机器上以提升安全性。

一旦 Vault 节点被解封,它将维持解封状态,除非发生以下的某种情况:

  1. 它被通过 API 重新封印了
  2. 服务重启了
  3. Vault 存储层发生不可恢复的错误

解封操作增加了自动化安装 Vault 的难度。自动化工具可以轻松地安装、配置和启动 Vault 服务,但使用 Shamir 算法解封服务依赖手工操作。大多数用户通过使用自动解封机制获得更好的体验。

封印

有特定 API 可以用来封印服务。该操作会将内存中的 Master Key 抛弃,然后必须再执行一次解封操作才能恢复它。封印操作只需要使用 Root 特权进行一次操作即可完成。

这样的话,如果检测到入侵的迹象,可以用最快的速度锁定 Vault 保存的机密来减少损失。如果没有办法恢复 Master Key 是无法访问 Vault 中的数据的。

自动解封

自动解封是一种用来降低解封操作复杂度同时确保解封密钥本身安全的机制。该功能将保管解封密钥的职责从用户这边转移到了一个可信的设备或者服务上。Vault 启动时会连接该设备或者服务,请求解密从存储中读到的 Master Key。

自动解封机制
图 1.3.2/2 - 自动解封机制

Vault 中除了解封以外有些特定的操作需要一组用户的多数批准才能执行,例如生成 Root 令牌。当使用 Shamir 算法封印时,需要多数用户输入他们的解封密钥。当使用自动解封时,这些操作需要的是“恢复密钥”(recovery keys)。

正如使用 Shamir 密封的初始化过程产生解封密钥一样,使用自动解封的初始化过程会产生恢复密钥。

注意,恢复密钥无法用来解密 Master Key,所以当自动解封机制无法工作时,无法使用恢复密钥解封 Vault。它们只能用来做授权验证。

即使使用自动解封,仍然可以通过调用 API 封印 Vault。一旦封印,Vault 会保持封印状态直到被重启,或是执行了解封操作。执行解封操作需要恢复密钥分片而不是解封密钥,其他流程是一样的。

恢复密钥的更新

恢复密钥可以被更新来更改分片数或是阈值(输入多少份密钥可以成功执行)。使用 Vault CLI 时,可以在执行 vault operator rekey 命令时添加 -target=recovery 参数。

封印迁移

封印迁移流程无法避免停机维护,并且由于实现封印的技术基础,该过程需要用户关闭整个集群。虽然无法避免一段停机,但我们认为更换封印是一种罕见的事件,停机时间带来的不便是一种可以接受的权衡。

执行封印迁移之前请先执行备份以避免出错。

封印迁移会同时需要新旧两套封印的基础设施在迁移期间保持可用。举例来说,如果要从自动解封迁移到 Shamir 封印,那么自动解封所需的服务必须在整个迁移期间保持可用。

从一种自动解封迁移到另一种同类型的自动解封(例如从 AWSKMS 迁移到另一个使用不同密钥的 AWSKMS)从 Vault 1.6.0 开始得到支持。从一种自动解封(例如 AWSKMS)到另一种不同的自动解封(例如 HSM、Azure KSM 等)在更老的版本上也是支持的。

Vault 1.5.1 后的迁移

以下是所有受支持类型和存储后端之间的封印迁移的常见步骤:

  1. 设置一台备用节点下线,并更新相关的封印配置。
    1. 如果是从 Shamir 封印迁移到自动解封,添加对应的自动解封配置节即可。
    2. 如果是从自动解封迁移到 Shamir 封印,在旧的封印配置节中添加 disabled = "true"
    3. 如果是从自动解封迁移到其它自动解封,在旧的封印配置节中添加 disabled = "true",然后添加新的封印配置节。

现在将备用节点重新上线,然后使用相关密钥运行解封命令,但要记得添加 -migrate 标记。

    1. 如果旧的封印机制是 Shamir 封印,那么需要提供 Shamir 解封密钥,然后会迁移到自动解封。
    1. 如果旧的封印机制是某种自动解封,那么需要提供恢复密钥,然后会迁移到新的自动解封或是 Shamir 封印。
  • 在所有剩余的备用节点上重复上述步骤,一次操作一个节点。在下线一台节点前要先把之前离线操作的节点重新恢复上线,特别是使用节点集成存储时尤其如此,需要确保在线节点数可以形成集群多数。

  • 下线主节点。这时备用节点之一会成为新的主节点。当使用节点集成存储时,要确保集群活动节点数达到了集群多数,并且选出了新的活动节点。

  • 新的主节点将执行迁移。在主节点监控服务器日志,确认封印迁移过程完成。如果使用节点集成集成存储,请稍等片刻,让迁移信息复制到所有节点。在 Vault 企业版中,切换自动解封意味着被封印保护的数据会被重新加密。监控日志并等待此过程完成。(参见 seal re-wrap completed 命令)

  • 封印迁移到此已经完成。下线旧的主节点,更新它的配置以使用新的封印配置节(完全不顾及旧的封印类型)并将其恢复上线。如果新封印是某种自动解封,它将自动解除封印;如果新封印是 Shamir 封印,则需要解封密钥执行解封。

  • 此时,所有节点的配置文件都可以更新为只有新的封印配置。更新配置后,备用节点可以立即重新启动,主节点可以在更改主节点时重新启动。

Vault 1.5.1 之前的封印迁移

暂时不翻了,如果有需要请提 issue。

results matching ""

    No results matching ""