推出 KES - 可扩展密钥管理

如今，大多数数据都经过加密。几乎所有应用程序都使用 TLS/HTTPS 加密其网络通信（传输中），并在存储数据之前单独加密数据（存储时）。

虽然了解数据是如何加密的很有趣，但我们今天想关注一个不同的问题——有时被认为是一个更难的问题。

应用程序如何获取加密密钥？

密钥管理系统

通常，应用程序每个数据对象都需要一个新的加密密钥。因此，应用程序通常会向密钥管理系统 (KMS) 请求数据加密密钥 (DEK)。传统上，KMS 是一个中心组件，它维护一组主密钥，并将它们存储在安全存储单元中——例如符合 FIPS-140 2 标准的硬件安全模块 (HSM)。

当应用程序需要加密某些数据时，它可以请求 KMS 从特定的主密钥派生一个新的 DEK。类似地，当应用程序需要再次解密某些数据时，它可以请求 KMS 使用相同的主密钥解密加密的 DEK。这样，应用程序永远不会看到任何主密钥——只有明文/密文 DEK 对——而 KMS 不需要存储每个加密密钥。

一个高级的 KMS，例如 Hashicorp Vault，非常适合保护您的主密钥。它还提供额外的加密 API 以及其他密钥管理功能，并且可以使用经过认证的硬件安全地存储密钥。这样的 KMS 可以充当您基础设施中的信任根。

但是，对于大型和分布式系统运行和管理功能齐全的 KMS 可能非常具有挑战性，特别是对于高性能应用程序而言。传统的 KMS 解决方案扩展性不佳。例如，扩展 KMS 硬件设备意味着购买更多昂贵的硬件。此外，功能齐全的 KMS 实现通常配置和维护起来相当复杂——以至于 KMS 管理需要一个专门的安全团队。这与现代运行高性能应用程序的基础设施不匹配，这些应用程序由 Kubernetes 自动调整以适应当前的工作负载。

在运行云原生基础设施时，您通常希望获得类似 AWS-KMS 的云 KMS 体验，但在本地环境中。

KES

KES 是一个用于高性能应用程序的无状态且分布式的密钥管理系统。它旨在在 Kubernetes 内部运行并将加密密钥分发给应用程序。需要明确的是，KES 无法也不能试图替代功能齐全的 KMS。相反，它充当中央 KMS 和云原生应用程序之间的桥梁。

因此，仍然有一个中央 KMS 保护主密钥并充当您基础设施中的信任根。但是，您不需要为每组应用程序部署和管理一个 KMS。相反，应用程序可以向 KES 服务器请求一个新的 DEK，或者请求 KES 服务器解密一个加密的 DEK。

由于 KES 服务器完全无状态，因此可以自动扩展——例如通过 K8S 水平自动扩展器。同时，中央 KMS 上的负载不会大幅增加，因为 KES 可以服务绝大多数应用程序请求，而无需与 KMS 通信。

保持简单

如前所述，KES 不是也不试图成为一个功能齐全的 KMS 实现。相反，它专注于一些非常常见的密钥管理操作，并通过易于使用的 REST API 公开它们——您只需要 cURL。

但是，简单的 API 只是一个方面。配置和管理 KES 服务器也非常容易——特别是与传统的 KMS 实现相比。KES 服务器是一个静态二进制文件，它使用 yaml 配置文件。将设置从开发人员笔记本电脑迁移到 Kubernetes 集群是一个无摩擦的体验。

但是，简单的设计不仅使开发和操作方面更容易。它还有助于保持系统的安全性。

保持安全

KES 旨在默认安全。例如，KES 只能在启用 TLS 的情况下运行。虽然这最初听起来像是一个限制，但它实际上有一些巧妙的含义。

首先，所有设置都使用安全通信，并且潜在的开发或测试环境在 TLS 方面与生产环境没有区别。通过要求使用 TLS，KES 还可以完全依赖 TLS 和 X.509 证书进行身份验证和授权。不需要额外的用户名/密码、JWT 或其他身份验证机制。TLS 是互联网上通用的身份验证机制，因此几乎每个人都支持它——无论底层操作系统或编程语言是什么。

但是，我们知道，理解 TLS 可能非常具有挑战性——尤其是在证书方面。因此，我们试图使工具抽象出底层细节。与几乎所有 MinIO 一样，如果您选择，可以深入了解细节，但您不应该需要这样做。

我们不会在这里解释所有细节，让我们从一些示例开始。

入门

如果您愿意，您可以按照我们的 入门指南 在一分钟内设置一个本地 KES 服务器。但是，我们还在 https://play.min.io:7373 运行一个公共 KES 服务器实例，供您试用和实验。

作为第一步，您需要获取 root 身份的私钥和证书。

curl -sSL --tlsv1.2 \
   -O 'https://raw.githubusercontent.com/minio/kes/master/root.key' \
   -O 'https://raw.githubusercontent.com/minio/kes/master/root.cert'

现在，您可以直接开始使用 KES 服务器 API。例如，您可以创建一个名为 my-key 的新主密钥——如果它不存在的话——通过以下方式：

curl -sSL --http2 --tlsv1.3 \
   --key root.key \
   --cert root.cert \
   -X POST 'https://play.min.io:7373/v1/key/create/my-key'

作为最后一个示例，我们通过以下方式从 my-key 主密钥请求一个新的 DEK 明文/密文对：

curl -sSL --http2 --tlsv1.3 \
   --key root.key \
   --cert root.cert \
   --data '{}' \
   -X POST 'https://play.min.io:7373/v1/key/generate/my-key'

对于进一步的实验，您可能希望使用 KES CLI 并将其指向我们的 play 实例。

export KES_SERVER=https://play.min.io:7373
export KES_CLIENT_KEY=root.key
export KES_CLIENT_CERT=root.cert

您可能希望监控那里发生的事情。

kes log trace

下一步

KES 是一个根据 AGPLv3 许可的开源项目。您可以在 Github 上找到它。目前，KES 可以使用 Hashicorp Vault 和 AWS SecretsManager + AWS-KMS 作为中央 KMS。如果您想将 KES 与其他 KMS 实现一起使用或有功能请求，只需打开一个 问题。

此外，我们的 对象存储服务器 已经依赖 KES 来实现使用 KMS 的 S3 服务器端加密。要详细了解 KES 的工作原理，请查看我们的 概念 页面或 KES 服务器 API 文档。如果您有任何其他问题，请加入我们传奇的 社区 Slack 频道——我们将帮助您解决问题。