语言 Chinese, Simplified

SEO Title

部署，采用和超越

与每个HashiCorp产品一样，采用Vault时，有一种“爬行，行走，跑步”的方法。因此，本文档旨在根据软件最佳实践和大型组织中大规模部署Vault的经验，就HashiCorp Vault部署和采用的每个阶段所需的步骤提供一些可预测性。本文档不是深入介绍Vault的文档，而是提供旅程的概述，适当时引用文档，并关注操作方面。

本文档的部分内容旨在成为组织Runbook的基础，描述通常在Vault中运行的某些过程。

第零天

Vault内部和密钥加密原理

HashiCorp Vault是一种秘密管理解决方案，通过程序化访问，可以通过系统访问人和机器。可以存储，动态生成秘密，并且在加密的情况下，可以将密钥作为服务使用，而无需公开底层密钥材料。

可以使用下图汇总秘密消费方面的工作流程：

Vault的主要界面是通过HTTP Restful API。 CLI和Web GUI都通过相同的API与Vault连接。开发人员将使用此API进行编程访问。除了通过此API之外，没有其他方法可以在Vault中公开功能。
为了消费秘密，客户（用户或应用程序）需要建立自己的身份。虽然Vault支持用户的通用身份验证平台，例如LDAP或Active Directory，但它还添加了基于平台信任以编程方式建立应用程序身份的不同方法，利用AWS IAM，Google IAM，Azure应用程序组，TLS证书和Kubernetes命名空间等等。在身份验证后，并且基于某些身份属性（如组成员身份或项目名称），Vault将授予与特定策略集对齐的短期令牌。
Vault中的策略与身份分离，并定义特定身份可以访问的秘密集。它们被定义为HashiCorp配置语言（HCL）中的代码。可以使用Sentinel规则定义丰富的策略，该规则旨在回答实体可以访问秘密的“在什么条件下”，而不是传统的“谁访问”常规ACL中定义的秘密。
Vault通过Syslog，File或Socket将审计信息发送到SIEM系统或记录后端。如果Vault无法正确提供审核信息，则不会响应。
最终，Vault可以动态存储或生成秘密。凭借“安装”发动机：
- 可以使用KV / 2引擎存储和版本化静态机密。
- 可以使用不同的引擎动态生成不同类型的秘密，包括数据库，SSH / AD访问，PKI（X.509证书）等
- 密钥材料可以通过提供加密/解密/签名/验证/ HMAC功能的特定端点来使用，而无需离开Vault。

可以使用下图汇总Vault内部体系结构：

从数据组织的角度来看，Vault具有伪分层API路径，其中可以安装顶级引擎来存储或生成某些机密，提供任意路径（即/ secret / sales / password）或预定义路径动态秘密（例如/ pki / issue / internal）。

没有秘密以未加密的形式离开加密屏障（仅存在于Vault主机上的易失性存储器中）。该屏障由一组键保护。通过HTTP API提供的信息使用TLS加密。存储后端中存储的信息使用存储密钥加密，存储密钥由主密钥加密，主密钥可选地由外部密封加密以便于操作，并自动执行开封过程，如下图所示。（有关详细信息，请参阅Vault体系结构）相同的密封也可用于加密机密。例如，对于需要以符合FIPS的方式加密的机密，Vault的“Seal Wrap”与HSM一起可用于实现此功能。

Vault HSM workflow

Vault HSM工作流程

Vault解决方案架构

HashiCorp Vault使用分布式系统概念和范例设计。因此，在部署方面有很多可能性，但只有少数可能由HashiCorp进行全面测试和支持。在单站点或多站点弹性和扩展要求方面，有不同的策略。出于本文档和任何架构决策的目的，您应将站点视为往返时间不超过8毫秒的地理区域。

单一网站

对于单个站点，Vault的生产部署是一个集群单元，通常由三个节点组成。在其开源变体中，一个节点自动被指定为“活动”，而其余两个节点处于“待机”模式（不主动提供服务）。当使用HashiCorp Consul时，这些“待机”节点将在“主动节点”（在这种情况下立即进行故障转移）有序关闭时自动执行“活动”角色，或者故障（在不干净的关闭下故障转移需要45秒），推荐的存储后端。使用Vault Enterprise Premium时，可以将备用节点设置为“性能备用”，这样可以通过直接回答某些查询来使它们水平扩展群集，同时透明地将其他节点转发到主动节点。簇。如前所述，Active和Standby节点之间的延迟存在严格限制。

Vault可以使用许多不同的存储后端。但是，HashiCorp仅使用Consul作为真正可扩展的生产级解决方案，为Vault集群提供支持。通常，Consul后端部署为5节点群集，以支持3节点Vault群集。

HashiCorp Consul必须始终保持法定人数以提供服务（N + 1个节点/投票），并且法定人数损失不是可接受的操作方案;因此，产品中有许多策略和自动驾驶仪功能可确保服务连续性和扩展，例如非投票成员，冗余区域和更新迁移。

最常见的单站点Vault部署如下所示：

上图中的Consul集群图标由下图中所示的组件组成（在这种情况下，Consul客户端将是Vault服务器）：

该架构旨在满足以下原则：

每个服务最多两个节点可能会失败而不会导致中断，但如果使用“性能备用”可能会导致性能下降，直到重新配置其他服务器。
系统分布在奇数个网络区域或可用区域，以适应最多整个区域的故障。
每个区域都有一个数据源（存储后端）和一个加密密封。

多个站点

HashiCorp Vault提供两种复制模式，其中主群集将有选择地将日志发送到辅助群集。

从弹性角度来看，最低要求是配置灾难恢复（DR）副本，它是一个热备份并拥有所有内容的完整副本。 DR副本在升级之前无法应答请求。从运营角度来看，DR副本将在以下情况下提供服务连续性：

数据篡改：意外或故意操纵存储后端，存储后端保存二进制加密数据。通过备份/恢复技术可以在一定程度上缓解这一方面，对DR副本不受RMP副本影响的RPO和RTO产生相当大的影响。
密封篡改：密钥是加密保证的组成部分，不可恢复。如果要删除或篡改加密密钥，则Vault将无法恢复。 DR副本具有单独的密封，应该对其进行隔离。
基础架构故障：如果主集群从网络或计算角度变得不可用，则可以升级DR副本以提供服务连续性而不会产生任何影响。

更常见的是，存在于多个地理位置的组织将创建一组性能副本，在地理上传播。虽然此设置可以在位置内提供秘密和配置的复制，但最重要的是它可以跨位置统一单个密钥环（主密钥和存储密钥），这对于在大规模使用Vault时减少操作开销至关重要。

在“性能复制”模式下，所选路径将复制到不同的群集，并且在辅助群集中执行尽可能多的操作以最大程度地减少延迟。两种复制模式可以组合在一起，这将允许广泛的操作效率和弹性，如附图所示。