在强大可靠的存储解决方案领域，MinIO 作为持久层脱颖而出，为组织提供安全、持久和可扩展的存储选项。MinIO 通常负责处理关键任务数据，在确保高可用性方面发挥着至关重要的作用，有时甚至在全球范围内。存储数据的性质，从财务和医疗保健记录到复杂的产品细节和尖端的 AI/ML 模型，不仅需要弹性，还需要严格的安全措施来防止未经授权的访问和披露。
MinIO 通过其细粒度身份和访问管理、对象锁定和端到端数据加密（静态和在线）等核心功能解决了这些安全问题。为了保护静态数据，MinIO 与各种密钥管理系统 （KMS） 无缝集成，包括 HashiCorp Vault、Thales CipherTrust Manager、AWS KMS 和 SecretsManager 等知名选项。这些 KMS 解决方案充当加密密钥的守护者，将它们安全地存储在远离它们保护的数据的地方。
虽然 MinIO 支持的 KMS 解决方案已经证明了它们的实力并被广泛使用，但也出现了一些挑战，尤其是在处理 PB 甚至 EB 数据的大规模存储基础设施的背景下。多年来观察到的局限性，部分通过我们的 KES 项目得到缓解，揭示了集成和维护单独的 KMS 解决方案的复杂性。
管理通用 KMS 会带来复杂性，因为这些 KMS 通常是错综复杂的分布式系统。兼顾安全性、合规性和性能需求成为一项艰巨的任务。另一方面，高性能存储基础架构的稳健性可能需要满足通用 KMS 解决方案难以满足的要求，尤其是在可用性、响应时间和整体性能方面。即使他们这样做了，它们也可能变得不可靠、过度资源消耗或成本上升。
因此，认识到大型、高可用性和高性能数据基础设施带来的独特挑战，我们致力于开发针对 MinIO 的 KMS，以满足这些特定需求。MinIO 的 KMS 功能专为我们的 Enterprise Lite 和 Enterprise Plus 客户提供。
MinIO 企业对象存储 KMS 是一种高度可用的 KMS 实现，针对大型存储基础设施进行了优化，特别是针对 MinIO 进行了优化。它的设计具有以下主要目标：
-
可预测的行为：MinIO 的企业 KMS 旨在易于管理，使操作员能够直观地理解其状态。由于其更简单的设计，MinIO 的企业 KMS 比依赖更复杂的共识算法（如 Raft 或 Paxos）的类似解决方案更容易操作。
-
高可用性和容错性：在大规模系统的动态环境中，网络或节点中断是不可避免的。关闭集群进行维护很少可行。MinIO 的企业 KMS 确保了不间断的可用性，即使面临此类中断，也可减轻可能破坏整个存储基础架构的级联效应。对于常见工作负载，KMS 提供尽可能高的可用性。具体而言，您可能会丢失集群中除一个节点之外的所有节点，但仍会处理任何加密、解密或数据密钥生成请求。
-
可扩展性：虽然数据量通常只会增加，但大规模存储系统的负载可能会不时发生显著变化。MinIO 的企业 KMS 支持动态集群大小调整，可以随时添加或删除节点，无需停机。
-
一致性和高性能：在大规模存储基础架构上，数据是不断写入和读取的。企业级 KMS 的响应能力直接影响存储系统的整体效率和速度。KMS 节点在处理来自存储系统的此类请求时不必进行协调。因此，KMS 集群的性能随节点数量的增加呈线性增长。此外，MinIO 的企业 KMS 支持请求流水线，以处理每节点和每秒数十万次加密操作。
-
多租户：大规模存储基础架构通常由整个组织中的许多应用程序和团队使用。将团队和组隔离到自己的命名空间中是一项核心要求。MinIO 的 Enterprise KMS 支持以围圈的形式命名空间。可以为每个租户分配自己的 enclave，该 enclave 完全独立，并与 KMS 集群上的所有其他 enclave 隔离。
KMS 可以在 Enterprise Console 或命令行中配置。
现在，让我们深入探讨 KMS 的运行方式，首先检查其基本安全模型，然后深入了解集群架构和管理，最后将其无缝集成到 MinIO 中。
安全模型
KMS 在（硬件）安全模块 （HSM） 上建立其基础信任，该模块在密封和解封 KMS 根加密密钥方面发挥着关键作用。HSM 的职责扩展到通过允许解封其加密的磁盘状态并促进 KMS 集群内节点之间的通信来保护 KMS 的完整性。
但是，HSM 是一个概念，不一定是实际的硬件设备。例如，可以使用云 HSM（如 AWS CloudHSM）或软件 HSM 来代替物理设备。KMS 实施自己的软件 HSM，优先考虑用户友好的实施和操作简单性。
在每个 MinIO KMS 服务器上设置单个环境变量就足以开始使用。例如：
export MINIO_KMS_HSM_KEY=hsm:aes256:vZ0DeGvwlb/KHwIfi8+c7/8ZHjweHKVL0WNrRc3+FxQ=
在单个 KMS 服务器上，所有数据都驻留在内存中或加密在磁盘上。但是，在运行分布式 KMS 集群时，节点必须交换消息。为了确保节点间通信的安全，KMS 使用双向 TLS，使用直接派生自 HSM 的密钥。因此，只有有权访问相同 HSM 的节点（例如共享相同的软件 HSM 密钥）才能通过节点间 API 建立通信。通过这种方式，HSM 具有双重目的，不仅作为整个系统的信任守护者，而且作为在节点间通信中建立信任的基石。
集群管理
KMS 集群是一种分布式系统，它使用单领导者同步复制将状态更改传播到所有集群节点，并根据投票选出领导者。它在概念上与 Raft 共识协议非常相似，但并不完全相同。它仍然严格一致，并为所有事件提供线性化。
但是，通过查看几个示例，可能更容易理解 KMS 的工作原理。运行 KMS 集群不需要加密或分布式系统方面的专业知识。
因此，让我们多动手一点，感受一下 KMS 集群的行为方式。在最简单的情况下，KMS 集群由单个节点组成。启动新的 KMS 服务器时，它会自动创建新的单节点集群。例如：
export MINIO_KMS_HSM_KEY=hsm:aes256:vZ0DeGvwlb/KHwIfi8+c7/8ZHjweHKVL0WNrRc3+FxQ
=
minkms server --addr :7373 /tmp/kms0
我们可以使用自动生成的 API 密钥以集群管理员身份向集群进行身份验证，并列出其所有节点。
export MINIO_KMS_API_KEY=k1:ThyYZWXUjlSOL-l5hldSgO49oQPWZezVZFU4aiejVoU
minkms ls
现在，我们已经启动并运行了第一个 KMS 集群，让我们为将来要使用的主密钥创建一个新的 enclave。如前所述，enclave 实现命名空间。一个 enclave 中的所有密钥都与驻留在其他 enclave 中的所有其他密钥完全隔离。
minkms add-enclave enclave-1
在 enclave 中，我们可以创建第一个主密钥并检查其状态
minkms add-key --enclave enclave-1 key-1
minkms stat-key --enclave enclave-1 key-1
到目前为止，我们只使用单个 KMS 服务器运行。现在，让我们将单节点集群从一个节点扩展到三个节点。因此，为了简单起见，我们将在同一台计算机上启动另外两个 KMS 服务器。
首先，第二台服务器：
export MINIO_KMS_HSM_KEY=hsm:aes256:vZ0DeGvwlb/KHwIfi8+c7/8ZHjweHKVL0WNrRc3+FxQ=minkms server --addr :7374 /tmp/kms1
然后是第 3 个：
export MINIO_KMS_HSM_KEY=hsm:aes256:vZ0DeGvwlb/KHwIfi8+c7/8ZHjweHKVL0WNrRc3+FxQ=minkms server --addr :7375 /tmp/kms2
现在，我们可以返回到初始的 KMS 单节点集群，并通过向其添加其他两个服务器来扩展它。因此，我们使用服务器的 IP 地址和端口号（或 DNS 名称和端口）。这里是 192.168.188.79，但这在您的机器上可能有所不同。使用服务器在启动时在控制台上打印的 IP 和端口。
minkms add 192.168.188.79:7374
minkms add 192.168.188.79:7375
当我们再次查询 KMS 集群的状态时，它会告诉我们它由三个节点组成 - 初始服务器和我们刚刚添加的两个节点。
minkms ls
现在我们已经将多个节点加入到一个集群中，所有节点是否都具有相同的状态？例如，节点 1 是否也能够为我们提供有关我们之前创建的 enclave enclave-1 中的密钥key-1的状态信息？我们可以通过直接询问节点来找出答案。此步骤同样取决于本地网络中使用的 IP 地址。进行相应调整。
MINIO_KMS_SERVER=192.168.188.79:7374 minkms stat-key --enclave enclave-1 key-1
当节点加入集群时，它们会接收整个 KMS 状态，并且只有在它们同步后才会被视为集群的一部分。因此，集群中的所有节点都是彼此的副本，并保存相同的数据。后台没有部分状态，也没有静默同步。这就是为什么 KMS 集群非常可预测的原因之一。它们不能不同步。
例如，我们可以关闭三台 KMS 服务器中的两台。从技术上讲，我们可以删除任何两个节点，但我们停止节点一和节点二。因此，我们不必调整MINIO_KMS_SERVER来确保与剩余的一个节点进行通信。完成后，我们可以再次列出群集节点。
minkms ls
正如预期的那样，三分之二的节点不可用。但是，我们仍然可以在剩余节点上查询 key-1 的状态。
minkms stat-key --enclave enclave-1 key-1
对于服务器以预期的输出进行响应，您可能不会感到惊讶。然而，其他 KMS 实现，例如使用 Raft 作为底层共识算法的实现，将无法响应，至少在不容忍过时和放弃强一致性的情况下无法响应。如果两个节点处于关闭状态，则三节点 Raft 集群通常被视为不可用，无法处理任何请求。主要区别在于，KMS 可以保持对所有读取请求的可用性，而不会削弱其一致性保证。幸运的是，大规模存储系统使用的大多数 KMS 操作不需要在 KMS 集群上更改状态，因此可以将其视为"只读"。因此，KMS 容错模型符合大规模存储系统对高可用性和可靠 KMS 的期望。这并非巧合。
但是，KMS 不能也不会规避 CAP 定理。尝试更改剩余节点的状态（例如通过创建第二个密钥）将失败。服务器无法接受写入操作，因为它可能会不同步。因此，我们必须先带回剩下的两个节点，然后才能创建新的主密钥。
然而，重要的是要认识到 KMS 在 CAP 定理的范围内运行，并且不能绕过其固有原则。任何更改剩余节点状态的尝试（例如创建第二个密钥）都将失败。服务器本质上被限制接受写入操作，以防止潜在的分歧和状态不一致。实际上，这意味着在创建新的主密钥之前，必须重新启动剩余的两个节点才能在集群内建立写入仲裁。
总结
我们的 Enterprise 和 Enterprise Lite 客户可以使用这项新功能，同时缩小攻击面，同时解决与数十亿个加密密钥相关的性能挑战。MinIO 企业对象存储 KMS 可以提供可预测的行为，即使在每秒每个节点数十万次加密操作的规模下，也能提供高可用性和容错能力。此外，KMS 还支持多租户，使每个租户都能分配自己的 enclave，该 enclave 完全独立，与 KMS 集群上的所有其他 enclave 隔离。