介绍KES-大规模密钥管理

今天，大多数数据都已加密。几乎所有应用程序都使用TLS / HTTPS加密其网络通信（进行中），并在存储数据之前对其进行单独加密（静态）。

尽管有趣的是如何看待数据如何加密，但我们想着眼于另一个当今（有时被认为更难解决）的问题：

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

密钥管理系统

通常，应用程序每个数据对象需要一个新的加密密钥。因此，应用程序通常从密钥管理系统（KMS）请求数据加密密钥（DEK）。传统上，KMS是维护一组主密钥并将其存储在安全存储元素（例如FIPS-140 2认证的硬件安全模块（HSM））中的中央组件。

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

像Hashicorp Vault这样的高级KMS非常适合保护您的主密钥。它还提供其他加密API以及其他机密管理功能，并且可以使用经过认证的硬件安全地存储机密。这样的KMS可以成为基础架构信任的基础。

但是，为大型和分布式系统运行和管理功能齐全的KMS可能会非常具有挑战性，尤其是对于高性能应用程序而言。传统的KMS解决方案无法很好地扩展。例如，扩展KMS硬件设备意味着购买更昂贵的硬件。此外，功能齐全的KMS实施通常配置和维护都非常复杂-扩展到KMS管理需要专门的安全团队。这确实与运行高性能应用程序的现代基础架构匹配，该基础架构由Kubernetes自动调整为当前工作负载。

在运行云原生基础架构时，通常需要本地的云KMS（如AWS-KMS）体验。

凯斯

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是Internet上的通用身份验证机制，几乎每个人都支持TLS-不管底层操作系统或编程语言如何。

但是，我们知道，将头缠绕在TLS上可能非常具有挑战性-尤其是在证书方面。因此，我们试图使该工具抽象出底层细节。与几乎所有MinIO一样，您可以选择深入了解杂草，但您不必这样做。

让我们从一些示例开始，而不是在这里解释所有详细信息。

入门

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

首先，您需要获取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并将其指向我们的播放实例：

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频道-我们将为您提供帮助。