如何实现零停机密钥轮换

Question

我在 AWS 中运行多个微服务，其中一些相互通信，其中一些具有外部客户端或成为外部服务的客户端。

为了实现我的服务，我需要许多秘密（用于签名/验证令牌的 RSA 密钥对、对称密钥、API 密钥等）。我正在为此使用 AWS SecretsManager，它运行良好，但我现在正在实施对密钥轮换的适当支持，我有一些想法。

• 我正在使用 AWS SecretsManager，定期（约 5 分钟）获取机密并将其缓存在本地。
• 我根据需要使用 AWS SecretsManager 的版本阶段功能来引用 AWSCURRENT 和 AWSPREVIOUS 版本。

假设服务 A 需要服务 B 的密钥 K：

• 假设在开始时，K 具有当前值 K1 和先前值 K0。
• 服务 A 将始终使用（并在本地缓存）K 的 AWSCURRENT 版本与 B 进行通信，因此在本例中 K1
• 服务 B 将在其本地缓存中保留版本 AWSCURRENT 和 AWSPREVIOUS 并接受 [K1, K0]
• 当轮换 K 时，我首先确保服务 B 使用的密钥已轮换，以便在刷新间隔过后，服务 B 的所有实例都接受 [K2, K1] 而不是 [K1, K0]。在刷新间隔过去之前，A 的所有实例仍然使用 K1。
• 当刷新间隔过去时，意味着 B 的所有实例都必须获取 K2，我会轮换服务密钥，以便 A 将使用 K1 或 K2，直到刷新间隔过去，然后仅使用 K2。
• 这样就完成了密钥轮换（但如果认为 K1 被泄露，我们可以再次轮换 B 的秘密以推出 K1 并得到 [K3, K2]）。

这是最好的方法还是还有其他方法需要考虑？

然后，在某些情况下，我有一个在同一服务中使用的对称密钥 J，例如用于加密某些会话的密钥。因此，在对服务 C 的一个请求中，会话使用密钥 J1 加密，然后需要在稍后阶段使用 J1 解密。我有多个 C 服务实例。

这里的问题是，如果相同的秘密用于加密和解密，则旋转它会变得更加混乱 - 如果密钥被旋转为具有值 J2 并且一个实例已刷新，以便它将使用 J2 加密，而另一个实例仍然没有看到J2，解密就会失败。

我可以在这里看到一些方法：

1. 分成两个具有单独轮换方案的秘密，并一次轮换一个，与上面类似。这增加了要处理的额外秘密的开销，具有相同的值（除了它们之间有一些时间轮换之外）

2. 让解密在失败时强制刷新秘密：

   • 加密始终使用 AWSCURRENT（J1 或 J2 取决于是否刷新）
   • 解密将尝试 AWSCURRENT 然后 AWSPREVIOUS，如果两者都失败（因为另一个实例使用 J2 进行加密并存储 [J1, J0]），将请求手动刷新密钥（[J2, J1] 现在已存储），然后尝试再次是 AWSCURRENT 和 AWSPREVIOUS。

3. 在密钥窗口中使用三个密钥，并始终使用中间的密钥进行加密，因为它应该始终位于所有其他实例的窗口中（除非它被旋转多次，比刷新间隔更快）。这增加了复杂性。

还有哪些其他选择？这似乎是一个标准的用例，但我仍然努力寻找最好的方法。

编辑 - - - - - - - - -

根据 JoeB 的回答，到目前为止我提出的算法是这样的：假设最初秘密的 CURRENT 值是 K1，PENDING 值是 null。

普通手术

• 所有服务定期（每 T 秒）查询 SecretsManager和自定义标签AWSCURRENT并全部接受（如果存在） -> 所有服务接受 [ =K1]AWSPENDINGROTATINGAWSCURRENT
• 所有客户都使用AWSCURRENT=K1

钥匙轮换

1. 为 PENDING 阶段设置新值 K2
2. 等待 T 秒 -> 所有服务现在接受 [ AWSCURRENT=K1, AWSPENDING=K2]
3. 添加ROTATING到K1版本+移动AWSCURRENT到K2版本+AWSPENDING从K2中删除标签（似乎没有标签的原子交换）。在 T 秒过去之前，一些客户端将使用 K2 和一些 K1，但所有服务都接受两者
4. 等待 T 秒 -> 所有服务仍然接受 [ AWSCURRENT=K2, AWSPENDING=K1] 并且所有客户端都使用AWSCURRENT=K2
5. 从 K1 上拆下载ROTATING物台。请注意，K1 仍然会有舞台AWSPREVIOUS。
6. T秒后，所有服务将只接受[ AWSCURRENT=K2]，K1实际上已死亡。

这应该适用于单独的秘密和用于加密和解密的对称秘密。

不幸的是，我不知道如何使用内置的旋转机制来实现这一点，因为它需要几个步骤，中间有延迟。一种想法是发明一些自定义步骤，并让该setSecret步骤创建一个 CloudWatch cron 事件，该事件将在 T 秒后再次调用该函数，并使用 stepsswapPending和 来调用它removePending。如果 SecretsManager 能够自动支持这一点，那就太棒了，例如支持函数返回一个值，指示应在 T 秒后调用下一步。

Answer 1

对于您的凭据问题，只要服务 B 支持两个活动凭据，您就不必在应用程序中同时保留当前和以前的凭据。为此，您必须确保凭证在准备就绪之前不会被标记为 AWSCURRENT。然后应用程序始终获取并使用 AWSCURRENT 凭证。要在旋转 lambda 中执行此操作，您需要执行以下步骤：

1. 使用阶段标签 AWSPENDING 将新凭证存储在机密管理器中（如果您在创建时传递阶段，则机密不会标记为 AWSCURRENT）。创建密钥时还可以使用提供给 lambda 的幂等性令牌，这样重试时就不会创建重复项。
2. 获取AWSPENDING阶段下秘密管理器中存储的秘密，并将其添加为服务B中的凭证。
3. 验证您是否可以使用 AWSPENDING 凭证登录到服务 B。
4. 将 AWSPENDING 凭证的阶段更改为 AWSCURRENT。

这些是机密管理器创建多用户 RDS 轮换 lambda 时所采取的相同步骤。请务必使用 AWSPENDING 标签，因为 Secrets Manager 对此进行了特殊处理。如果服务 B 不支持两个活动凭据或多个用户共享数据，则可能无法执行此操作。请参阅有关此内容的秘密管理器轮换文档。

此外，Secrets Manager 轮换引擎是异步的，并且会在失败后重试（这就是每个 Lambda 步骤必须是幂等的原因）。有一组初始重试（大约 5 次），然后每天进行一些重试。您可以利用这一点，通过异常使第三步（测试秘密）失败，直到满足传播条件。或者，您可以将 Lambda 执行时间延长至15 分钟，并休眠适当的时间以等待传播完成。然而，睡眠方法的缺点是不必要地占用资源。

请记住，一旦您删除待处理阶段或将 AWSCURRENT 移至待处理阶段，轮换引擎就会停止。如果应用程序 B 接受当前和待处理（或者如果您想更加安全，则接受当前、待处理和上一个），如果添加您所描述的延迟，则上述四个步骤将起作用。您还可以查看AWS Secrets Manager 示例 Lambda，了解如何操作数据库轮换阶段的示例。

对于您的加密问题，我见过的最好方法是将加密密钥的标识符与加密数据一起存储。因此，当您使用密钥 J1 加密数据 D1 时，您可以存储或以其他方式传递给下游应用程序，例如应用程序的秘密 ARN 和版本（例如 V）。如果服务 A 在消息 M(...) 中向服务 B 发送加密数据，它将按如下方式工作：

1. A 获取阶段 AWSCURRENT 的密钥 J1（由 ARN 和版本 V1 标识）。
2. A 使用密钥 J1 将数据 D1 加密为 E1，并在消息 M1(ANR, V1, E1) 中将其发送给 B。
3. 随后 J1 轮换为 J2，并且 J2 被标记为 AWSCURRENT。
4. A 获取阶段 AWSCURRENT 的密钥 J2（由 ARN 和 V2 标识）。
5. A 使用密钥 J2 将数据 D2 加密为 E2，并在消息 M2(ANR, V2, E2) 中将其发送给 B。
6. B 收到 M1 并通过指定 ARN、V1 获取密钥（J1），并解密 E1 得到 D1。
7. B 收到 M2 并通过指定 ARN、V2 获取密钥（J2），并解密 E2 得到 D2。

请注意，密钥可以由 A 和 B 缓存。如果要长期存储加密数据，则必须确保密钥不会被删除，直到加密数据不再存在或使用以下命令重新加密：当前的密钥。您还可以通过传递不同的 ARN 来使用多个密钥（而不是版本）。

另一种选择是使用KMS进行加密。服务 A 将发送加密的 KMS 数据密钥，而不是密钥标识符以及加密的有效负载。B 可以通过调用 KMS 来解密加密的 KMS 数据密钥，然后使用该数据密钥来解密负载。