概念

欢迎来到 KES 文档站点。这些页面提供了关于 KES 如何工作的高级概述，包括 KES 组件信息、通用架构和访问控制。

有关设置 KES 的更详细文档，请参阅配置指南。

考虑一个基本设置，其中包含一个应用程序实例和一个 KES 服务器。

应用程序通过TLS连接到 KES 服务器。然后，应用程序使用 KES 服务器 API 执行诸如创建新的加密密钥之类的操作。KES 服务器与中央密钥管理系统 (KMS) 通信。

中央 KMS 包含所有状态信息，包括加密密钥。对于任何有状态操作（例如创建加密主密钥），KES 服务器都会联系 KMS。

KES 服务器直接处理无状态操作，例如生成新的数据加密密钥 (DEK)，无需与中央 KMS 交互。由于大多数密钥管理操作都是无状态的，因此 KES 服务器处理负载，包括加密、解密和密钥派生操作。

更大的工作负载需要更大的资源，需要更多应用程序实例。如果所有这些实例都直接与传统的 KMS 通信（例如专用服务器或硬件设备），它们最终将超过 KMS 的能力。

Kubernetes 会根据当前工作负载自动添加或删除资源。但是，旨在保护加密密钥的硬件安全设备通常无法自动扩展。对于那些支持集群的设备，扩展意味着购买更昂贵的硬件。

相反，KES 可以水平扩展以适应应用程序。

KES 服务器将应用程序与 KMS/密钥库分离，并且可以独立处理几乎所有应用程序请求。它只需要在创建或删除加密密钥时与密钥库通信。

类似地，KES 服务器仅使用 KMS 对存储在密钥库中或从密钥库中获取的加密密钥进行加密或解密。因此，KES 服务器将 KMS/密钥库上的负载降低了几个数量级。

通常，所有 KES 服务器操作都需要身份验证和授权。但是，KES 对两者都使用相同的应用程序独立机制：双向 TLS 身份验证 (mTLS)。

KES 客户端需要一对私钥/公钥以及X.509 证书。在下一节中，我们将明确区分公钥和证书，以解释身份验证和授权的工作原理。

KES 依赖于双向 TLS (mTLS) 进行身份验证。KES 客户端和 KES 服务器都需要自己的私钥/证书对。

默认情况下，每个 mTLS 对等体都必须信任对等体证书的发行机构。这意味着客户端必须信任服务器证书的发行机构，而服务器必须信任客户端证书的发行机构。如果同一个机构发行了客户端证书和服务器证书，那么客户端和服务器只需要分别信任一个实体。如果不同的机构发行了客户端证书和服务器证书，那么客户端和服务器必须分别信任这两个机构。

使用 扩展密钥用法 扩展，证书描述了特定公钥的有效用例。在 mTLS 的情况下，客户端证书必须包含一个包含 客户端身份验证 的扩展密钥用法。类似地，服务器证书必须包含一个包含 服务器身份验证 的扩展密钥用法。如果您的设置未按预期工作，请检查证书是否包含正确的扩展密钥用法值。

openssl x509 -noout -text -in <your-certificate.cert>

通常，KES 服务器仅接受来自可以在 TLS 握手期间提供有效且真实的 TLS 证书 (📜) 的客户端的 TLS 连接。

• 有效 证书表示证书格式正确且未过期。
• 真实 证书表示 KES 信任签署和颁发证书的证书颁发机构。

当 KES 客户端尝试建立与 KES 服务器的连接时，TLS 协议会检查以下内容：

• KES 客户端拥有与客户端提供的证书 (📜) 中的公钥相对应的私钥 (🗝️)。
• 客户端提供的证书是由 KES 服务器信任的证书颁发机构 (CA) 颁发的。

如果 TLS 握手成功，则 KES 服务器认为请求是真实的。

可以在测试或开发期间跳过证书验证。

1. 使用 --auth=off 选项启动 KES 服务器。
2. 然后，客户端仍然提供证书，但服务器不会验证证书是否由受信任的 CA 颁发。相反，客户端可以提供自签名证书。

在确定请求的真实性后，KES 服务器会检查客户端执行请求操作的授权。KES 依赖于基于角色和策略的授权模型。授权检查将请求与与客户端关联的策略进行比较。

当 KES 服务器收到真实的客户端请求时，它会使用客户端的公钥从客户端证书计算客户端的身份。计算出身份后，KES 服务器会检查该身份是否具有关联的命名策略。如果存在这样的身份-策略映射，则 KES 服务器会验证请求是否符合该策略。否则，服务器将拒绝该请求。

KES 服务器策略决定是否允许客户端请求。策略包含一组规则，这些规则定义在哪些资源上允许或拒绝哪些 API 操作。KES 使用旨在提高人类可读性和理解性而非灵活性的策略定义。

通常，策略模式具有以下格式

/<API-version>/<API>/<operation>/[<argument0>/<argument1>/...]

例如

将每个允许/拒绝规则编写为 glob 模式。glob 模式允许单个规则匹配整个请求类别。

KES 服务器评估策略如下：

1. 评估所有拒绝模式。如果任何拒绝模式匹配，则使用 策略禁止 错误拒绝请求。
2. 评估所有允许模式。如果至少有一个允许模式匹配，则 KES 接受请求。
3. 如果没有任何允许模式匹配，则使用 策略禁止 错误拒绝请求。

让我们看一个策略示例

policy:
  my-policy:
    allow:
    - /v1/metrics
    - /v1/key/create/my-key
    - /v1/key/generate/my-key*
    - /v1/key/decrypt/my-key*
    deny:
    - /v1/key/*/my-key-internal*

my-policy 包含四个允许规则和一个拒绝规则。

KES 首先处理拒绝规则。my-policy包含一个拒绝规则，该规则阻止对所有名称前缀为my-key-internal的资源（即密钥）执行任何密钥 API 操作（key/*/）。如果客户端使用具有该前缀的密钥提交任何类型的 API 操作，KES 将禁止它。例如，根据此策略，KES 将拒绝以下任何操作：

• /v1/key/create/my-key-internal
• /v1/key/generate/my-key-internal
• /v1/key/generate/my-key-internal2

如果请求与任何拒绝模式都不匹配，则 KES 会针对允许规则评估请求。

在my-policy的情况下，KES 允许根据策略请求创建名为my-key的密钥。如果用户尝试创建名为my-key2或任何其他字符组合的密钥，则请求将返回策略禁止错误，因为没有允许规则与请求匹配。

当用户请求生成新的数据加密密钥 (DEK) 或解密加密的 (DEK) 时，策略允许任何名称前缀为my-key的密钥。KES 允许/v1/key/generate/my-key或/v1/key/generate/my-key2，但禁止/v1/key/generate/key-to-generate1。

• 有关策略和更多示例的更多信息，请参阅：策略配置
• 有关 KES 服务器 API 的全面概述，请参阅：服务器 API

策略-身份映射是一对多关系，这意味着您可以将许多身份关联到同一策略。但是，您一次只能将一个身份关联到 KES 服务器上的一个策略。

多个 KES 服务器可以分别拥有自己的策略-身份关系集。例如，KES 服务器Server1可以将身份Ann关联到策略Policy1，KES 服务器Server2可以将同一身份Ann关联到不同的策略Policy2。
两个 KES 服务器Server1和Server2具有不同的独立策略-身份关系。

如前所述，KES 服务器根据客户端证书计算客户端身份。这通常计算为加密的 SHA-256 值。但是，在指定身份-策略映射时，将任意身份值关联到策略是完全有效的。关联的身份可以是"_"、"disabled"、"foobar123"或任何其他值。这对于处理特殊的root身份特别有用。

KES 服务器具有一个特殊的root身份，您**必须**指定它。您可以通过 KES 配置文件或--root CLI 选项指定root身份。通常，root的行为类似于任何其他身份，但它不能关联到策略。相反，root可以执行任意 API 操作。

root身份对于初始配置和管理任务特别有用。

集中管理或自动化的部署（例如 Kubernetes）不需要root身份，因为它只是一种安全风险。如果攻击者获得了root身份的私钥和证书，则攻击者可以执行任意操作。

即使必须始终指定root 身份，您也可以有效地禁用它。这可以通过指定一个root 身份值来实现，该值**永远不会**是实际的（SHA-256）哈希值。例如 --root=_（下划线）或 --root=disabled。由于 KES 永远不会为 _ 或 disabled 计算加密身份，因此无法以root身份执行操作。