在 Lambda 内存与临时缓存中缓存 JWKS

Question

我目前正在为我的 Lambda 自定义授权函数使用 the Auth0 JWKS library 检索 JWKS 密钥。

正如this issue on the JWKS library 中所解释的，显然 JWKS 中内置的公钥 ID 缓存不适用于 lambda 函数，因此他们建议将密钥写入 tmp 文件。

cache=true 不起作用的原因有哪些？

据我所知，应该没有区别会阻止内存缓存与 lambda 函数一起使用，但允许在 tmp 文件夹上进行基于文件的缓存是合适的解决方案。

据我所知，唯一会发生的问题是容器速率限制 JWKS API 的产生，而不是使用创建的容器的内存进行缓存的行为。

在这种情况下，将此令牌外部存储在 Lambda 中的最佳模式是什么？

Answer 1

有很多选择如何解决这个问题。各有优缺点。

首先，将密钥存储在内存或磁盘上 (/tmp) 在持久性方面具有相同的结果。两者都可通过调用对同一个 Lambda 实例。

我建议将密钥存储在内存中，因为内存访问比从文件中读取（在每次请求时）要快得多。

以下是解决此问题的其他选项：

1. 将密钥存储在 S3 中并在初始化期间下载。
2. 将密钥存储在 EFS 卷上，将该卷装载到您的 Lambda 实例中，在初始化期间从该卷加载密钥。
3. 在初始化期间从 API 下载密钥。
4. 使用 Lambdas 部署包打包密钥，并在 在初始化期间从磁盘加载它们。
5. 将密钥存储在 AWS SSM 参数存储中并在初始化期间加载它们。

您可能已经注意到，“初始化期间”阶段是所有这些解决方案中最重要的部分。您不想对每个请求都这样做。

选项 1 和 2 需要您构建的其他“应用程序”定期下载密钥并将它们存储在 S3 或 EFS 卷上。这是额外的努力，但在某些情况下对于更复杂的设置可能是一个好主意。

选项 3 基本上是您目前已经在做的事情，并且可能是简单用例的简单性和合理工程之间的最佳权衡。如前所述，您应该将密钥存储在内存中。

选项 4 是一种有效的“破解”方法，它是获取 Lambda 密钥的最简单方法。我绝不建议这样做，因为突然更改密钥将需要重新部署 Lambda，同时请求无法通过身份验证，从而导致停机。

选项 5 可以是选项 3 的有效替代方案，但需要由另一个应用程序（如选项 1 和 2）进行相同的密钥管理。因此它不一定适合简单的授权方。