开源KMS之vault part1

vault 是HashiCorp出品的一款久经考验的机密管理软件，HashiCorp家的terraform也很有名，改天有空再写terraform相关的。

vault的架构之类的，官网上都用，这里就不过多介绍。

下面部分内容是来自官方文档的翻译，还有些是自己学习过程中的补充。

vault服务架构

生产环境推荐的架构

生产环境，推荐使用3节点vault + 3节点的consul， consul负责数据存储，3节点vault用于高可用集群。

高可用模式

https://developer.hashicorp.com/vault/docs/internals/high-availability

https://lonegunmanb.github.io/essential-vault/2.%E5%9F%BA%E6%9C%AC%E6%A6%82%E5%BF%B5/12.%E9%AB%98%E5%8F%AF%E7%94%A8%E6%A8%A1%E5%BC%8F.html

资源配额

https://developer.hashicorp.com/vault/tutorials/operations/resource-quotas

个人观点： 不建议生产上设置资源配额。因为如果达到配额后，如果程序代码不健壮的话，可能直接就阻断业务流程了。

与 Vault 的每一次交互，无论是将机密放入键/值存储中还是为 MySQL 数据库生成新的数据库用户名密码，都需要调用 Vault 的 API。

这种通过 API 驱动的模型的一个副作用是，应用程序和用户可能会发送一系列高频的 API 请求使系统资源不堪重负，从而导致某些 Vault 节点甚至整个 Vault 集群出现拒绝服务问题。当 Vault API 端点暴露于部署在全球基础设施中的数千或数百万个服务时，这种风险会显着增加，尤其是为内部开发人员的服务而部署的 Vault 服务。

Vault 提供了资源配额功能，允许 Vault 操作员指定对 Vault 中使用的资源的限制。具体来说，Vault 允许维护者创建和配置 API 速率限制。

Vault 允许操作员创建速率限制配额，使用令牌桶算法强制执行 API 速率限制。创建配额时可以指定路径，可以在根级别、命名空间级别或挂载点上定义速率限制配额。速率限制器基于每个 Vault 节点应用于每个唯一的客户端 IP 地址（速率限制配额的消耗信息不会再集群内复制）。客户端可以在任意 1 秒内发起 rate 次请求，每秒都是如此。

在根级别（也就是 path 为空）定义的速率限制配额会被所有命名空间和挂载点继承。它将充当整个 Vault API 的单一速率限制器。在命名空间级别定义的限速配额优先于全局限速配额，为挂载点定义的限速配额优先于全局和命名空间级别的限速配额。换句话说，更具体的配额规则更优先。

可以使用可选的 block_interval 创建速率限制，如果设置为非零值时，任何达到速率限制阈值的客户端都将在 block_interval 秒的持续时间内被屏蔽所有后续请求。

Vault 还允许通过公开的各种指标和启用可选的审计日志来检查 Vault 节点中的速率限制状态。

租约、续约以及吊销

对于每个动态机密和 service 类型登录令牌，Vault 都会创建一个租约（lease）：包含持续时间、是否可续约等信息的元数据。 Vault 承诺数据在给定的持续时间(Duration)或生存时间 (TTL) 内有效。一旦租约到期，Vault 可以自动吊销数据，过期后机密的使用者无法再确定它是否还是有效（因为吊销机密是一个异步操作，无法预测 Vault 将在何时执行吊销操作）。

这带来一个明显的收益：机密的使用者需要定期与 Vault 通信以续约（如果允许的话），或是请求一个新的机密。这使得 Vault 审计日志更有价值，也使密钥滚动更新变得更加容易。

Vault 中的所有动态机密都需要有租约。即使数据旨在永久有效，也需要租约以强制使用者定期续约。

除了续约，租约也可以吊销。当租约被吊销时，它会立即使该机密无效并阻止任何新的的续订。例如，使用 AWS 机密引擎，一旦租约被吊销，访问密钥就会从 AWS 中删除，这使得访问密钥从那时起变得无效。

吊销可以通过 API 手动进行，也可以通过执行 vault lease revoke 命令进行，也可以由 Vault 自动进行。当租约到期时，Vault 会自动吊销该租约。当令牌被吊销时，Vault 将吊销使用该令牌创建的所有租约。

需要注意的是，Key/Value 机密引擎是不关联租约的，虽然它有时也会返回一个租约期限。

vault的部署

本机地址 192.168.31.181

系统版本 centos 7.9

Vault版本： v1.15.4

启动consul单机版

$ ./consul --version
Consul v1.18.2
Revision 9fc827ca
Build Date 2024-05-16T19:10:00Z

./consul agent -server  -bootstrap-expect 1 -ui -node=node73 -config-dir=./ --data-dir=./data/ -bind=192.168.31.181 -client 0.0.0.0

启动vault单机版

编写配置文件如下 cat config.hcl

ui = true
disable_mlock = true

storage "consul"{
  address = "192.168.31.181:8500"
  path    = "vault/"
}

listener "tcp"{
  address     = "192.168.31.181:8200"
  tls_disable = 1
}

api_addr = "http://192.168.31.181:8200"
cluster_addr = "https://192.168.31.181:8201"

前台启动

vault server -config=config.hcl

初始化vault

会生成 5 个秘钥，一个 Root 用户的 Token。真实场景下，这 5 个秘钥会分配给 5 个不同的人员管理。 至少正确输入 3 个秘钥，才能解封 Vault。

#  export VAULT_ADDR='http://192.168.31.181:8200'

$ vault operator init
Unseal Key 1: sFavodROjxBhaxKLMfBCoSPmOmMuWJt2ecAkIDc9aFCW
Unseal Key 2: GbWHxL1itgGUFSg8xbVYxHBJH/aKVupapzbmEL+rLWZg
Unseal Key 3: +Zmuwyt1wT/sGqJUg/VcAh8n9IlshkqzLIKXAXJ55vaJ
Unseal Key 4: KzhIZ8Ro07yLmU80PvEnUNnvTGtubLtmN7QBaXulvgzG
Unseal Key 5: yxRhYFJ/pILzlsVceLEjlraBpxSIvBuPvABweLZ3dZwv
Initial Root Token:  hvs.BwHLss1Dmh9Be30uKVHAAlD5

Vault initialized with 5 key shares and a key threshold of 3. Please securely
distribute the key shares printed above. When the Vault is re-sealed,
restarted, or stopped, you must supply at least 3 of these keys to unseal it
before it can start servicing requests.

Vault does not store the generated root key. Without at least 3 keys to
reconstruct the root key, Vault will remain permanently sealed!

It is possible to generate new unseal keys, provided you have a quorum of
existing unseal keys shares. See "vault operator rekey" for more information.

更多关于vault的操作，留到下一篇。