概念

欢迎访问 KES 文档站点。 这些页面提供了 KES 工作原理的高级概述，包含 KES 组件信息、整体架构和访问控制相关内容。

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

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

应用程序通过连接到 KES 服务器TLS然后，应用程序使用 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对等方都必须信任对等方证书的颁发机构。 这意味着客户端必须信任服务器证书的颁发机构，服务器也必须信任客户端证书的颁发机构。 如果客户端证书和服务器证书由同一机构颁发，那么客户端和服务器各自只需信任单个实体。 如果客户端证书和服务器证书由不同机构颁发，那么客户端和服务器必须各自信任这两个机构。

随着Extended Key Usageextension, the certificate describes the valid use cases for a particular public key. 在mTLS的情况下，客户端证书必须包含一个扩展密钥用法Client Authentication同样，服务器证书必须包含一个扩展密钥用法，其中包含Server Authentication如果您的设置没有按预期工作，请检查证书是否包含正确的扩展密钥用法值。

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

通常，KES服务器只接受在TLS握手期间能够提供有效且真实的TLS证书（📜）的客户端的TLS连接。

• A 有效证书意味着该证书格式正确且未过期。
• An 真实的证书意味着 KES 信任签署并颁发该证书的证书颁发机构。

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

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

如果TLS握手成功，则KES服务器认为该请求是经过认证的。

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

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

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

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

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

一般来说，策略模式具有以下格式：

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

例如：

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

KES服务器按以下方式评估策略：

1. 评估所有拒绝模式。 如果任何拒绝模式匹配，则拒绝该请求并返回prohibited by policy错误。
2. 评估所有允许模式。 如果至少有一个允许模式匹配，KES 就会接受该请求。
3. 如果没有任何允许模式匹配，则拒绝该请求并返回prohibited by policy错误。

让我们来看一个示例策略：

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*

Themy-policy包含四条允许规则和一条拒绝规则。

KES 处理deny规则优先。my-policy包含一个拒绝规则，阻止任何关键API操作（key/*/) 对于所有具有名称前缀的资源（即键）my-key-internal如果客户端使用带有该前缀的密钥提交任何类型的 API 操作，KES 将禁止该操作。 例如，在此策略下 KES 将拒绝以下任何请求：

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

如果请求不匹配任何denypattern, KES 会根据以下条件评估请求：allow规则。

在...的情况下my-policyKES 允许在策略下创建名为my-key如果用户尝试创建一个名为my-key2或任何其他字符组合，请求将返回prohibited by policy错误，因为没有allow规则匹配该请求。

当用户请求生成新的数据加密密钥（DEKs）或解密已加密的（DEKs）时，该策略允许任何名称前缀为my-keyKES 允许使用/v1/key/generate/my-key or /v1/key/generate/my-key2但是禁止/v1/key/generate/key-to-generate1.

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

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

多个KES服务器可以各自拥有自己的策略-标识关系集。 例如，KES服务器Server1可以关联身份Ann根据政策Policy1KES服务器Server2可以将相同的身份关联起来，Ann改为不同的策略，Policy2.
两个KES服务器Server1和Server2拥有独特且独立的策略-身份关系。

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

KES服务器有一个特殊的root你所认同的身份必须指定。 您指定root通过KES进行识别配置文件或者--rootCLI 选项。 一般来说，root行为类似于任何其他身份，只是它不能与策略关联。root可以执行任意API操作。

Theroot身份在初始配置和管理任务中特别有用。

集中管理或自动化部署，例如Kubernetes, 不需要root身份，这只会带来安全风险。 如果攻击者获得了访问权限，root身份’的私钥和证书，攻击者可以执行任意操作。

尽管一个root身份必须始终被指定，你可以有效禁用这可以通过指定一个root标识值将从不成为一个实际的（SHA-256）哈希值。 例如--root=_（下划线）或--root=disabled由于 KES 从不计算加密身份_ or disabled，执行操作变得不可能root.