先旋转x在旋转y 在旋转z

目前，我正在Kubernetes之上构建多租户SaaS，我们遵循的一个原则是所有秘密都应该定期轮换。 我对如何在Kubernetes中提供此配置的最佳实践文档的明显缺乏感到惊讶。

当然，在证书方面，使用cert-manager来旋转证书相当简单，但是即使这样还不能完全解决-虽然可以旋转服务证书，但没有直接的方法可以为证书旋转证书。它和它通过信任进行身份验证的其他服务的CA。

对于不基于证书的身份验证（例如对称加密密钥，密码或用于JWT的事物的非对称密钥），实际上并没有什么方法可以做到。

当然，这绝对是可行的，而且我可以在不停机的情况下想出多种不同的方法来做到这一点。 还有多种第三方解决方案（例如HashiCorp Vault）使之成为可能。 但是我想使用Kubernetes原生机制–毕竟，Kubernetes确实提供了秘密管理API，应该可以以支持秘密轮换的方式使用它。

因此，我将提出一个约定，可能会成为一种最佳实践，以关于如何以与秘密轮换兼容的方式来管理Kubernetes中的秘密。 我建议的都是手动的，但是围绕这种方法构建工具以使其自动化应该不难。

一些原则

首先，为了使秘密轮换发挥作用，我需要概述一些原则。

应该从文件系统读取并重新读取机密

Kubernetes机密的一大优点是，当作为文件系统卷安装时，使用机密的Pod可以立即获得对机密的更新。 无需重新启动或重新部署，您所要做的就是更新密码。 但是，要利用此优势，使用机密的代码必须从文件系统中读取它。 它不适用于使用环境变量传递的机密。 此外，代码必须至少定期地从文件系统中重新读取机密，否则它将无法接收更改。

在Akka为加密密钥和证书配置它方面，我们已经取得了成功。 读取机密时，我们会跟踪读取机密的时间戳。 下次访问证书时（下次我们接收或建立新的TLS连接），如果时间戳记早于5分钟，则会重新读取它。 这样，我们可以在不中断服务的情况下旋转秘密。

机密必须由ID标识

对于TLS证书，密钥的ID内置在证书中，并且TLS实现通常可以配置为使用多个受信任证书。 对于JWT，有一个半内置机制，您可以在密钥ID JWT参数中设置密钥ID。 但是，大多数JWT实现不会默认设置您的设置，并且有时仅提供有限的支持（如果有）支持基于传入的密钥ID动态选择要使用的密钥。

加密任意数据时，通常没有任何内置机制来指示所使用密钥的ID。 就我而言，当我们加密少量数据时，我们使用的格式是<keyid>:<base64ed initialization vector>:<base64ed cypher text> 。 这使我们可以将每个加密数据与用于加密的密钥相关联。

对于密码，这又变得越来越困难，因为通常一次只能使用一个密码。 这里的一种可能性是支持多个用户名，并使用用户名作为密钥ID。

旋转机构

设定了遵循使用我们的秘密的代码的原则后，我们现在可以提出一种在Kubernetes中配置和旋转秘密的机制。

Kubernetes机密允许多个键值对。 我们可以利用这一点。 当这些秘密作为卷安装时，文件名对应于键值对中的键。 给定秘密密钥和密钥值密钥之间的名称冲突，我将把密钥值密钥称为文件名。

考虑一下您可能有一个对称密钥（可能用于对JWT签名）的情况。 每个密钥将获得一个标识符，可以简单地是一个计数器，一个时间戳，一个UUID等。当仅使用一个密钥时，文件名可能是<key-id>.key 。 当您的代码加载密钥时，它将在卷装载目录中查找名为*.key任何文件，并将全部加载，并将它们存储在密钥ID到实际密钥内容的映射中。

现在，这在验证JWT时非常有用，因为在开始之前您具有密钥ID，而您只需要选择该密钥ID的机密即可。 但是，在创建JWT时，如果您配置了多个键，则使用哪个键？ 重要的是，选择正确的密钥，如果机密只是刚刚被更新以添加第二个密钥，则其他Pod可能尚未拿起第二个密钥，因此，如果您使用第二个密钥对JWT进行签名并发送，对于这些吊舱，他们可能无法对其进行验证。 因此，要解决此问题，我们还将支持通过将其命名为<key-id>.key.primary来指定主要机密。 只能有一个主要机密，并且永远是用于签名或加密数据的机密。

因此，有了这个设置，这就是我们的旋转机制：

• 给定的秘密以配置的单个密钥开始，假设其ID为r1 。 id可以是任何东西，我们使用r表示修订，使用1表示它的第一个密钥，但是id可以是UUID或其他任何值。 密钥将放置在Kubernetes机密中，文件r1.key.primary 。
• 当需要旋转密钥时，将生成一个新密钥，并分配一个新的id r2 。 kubernetes秘密将被更新，以使其现在同时具有两个密钥，其中r1.key.primary是旧密钥的文件名，而r2.key是第二个密钥的文件名。
• 一旦确定所有节点都拾取了新密钥，就可以将新密钥更改为主密钥。 因此，机密将再次更新，其中r1.key是旧密钥的文件名，而r2.key.primary是新密钥的文件名。
• 一段时间之后，例如，一旦确定由旧密钥签名的所有JWT都已过期，我们将删除旧密钥，更新密钥，使其仅包含一个密钥，文件r2.key.primary 。

当秘密包含多个部分（例如非对称密钥或自签名证书）时，这种方法也可以使用，只需将key替换为事物的名称，例如，我可能拥有r2.private和r2.public或r2.crt 。

何必呢？

某人自己实现上述目标并不难，但是为什么不建议将其作为最佳实践呢？ 如果上述方法将被许多不同的人采用，则将打开以下可能性：

秘密消费支持

秘密使用者可以为该约定提供内置支持。 例如，一个JWT实现可能会提供它，用户只需要将其传递给目录以查找密钥，它将使用它们，并定期重新读取和使用新密钥。 HTTP服务器和客户端也可以这样做，数据库驱动程序也可以这样做。 可以提供实现该约定的泛型库，以便任意秘密使用（例如用于加密）可以轻松使用密钥。

自动旋转

如果有足够的消费者使用该约定，则可以实施自动秘密轮换的工具。 这就像操作员一样简单，它允许您配置要生成和旋转的机密，并提供给定的参数，例如轮播机密的频率，将新机密设为主要机密之前要等待的时间，然后等待多长时间。删除旧机密之前。 这样的工具还可以配置为创建并等待迁移作业，以允许使用新密钥解密和重新加密静态加密的数据。

利弊

优点

在上面的解释中，许多专家都是不言而喻的，但我能想到的还有更多：

不特定于Kubernetes

代码使用密钥的方式根本不是特定于Kubernetes的。 它可以在可以使用文件系统传递密钥的任何平台上工作。 这包括可能使用静态密钥的开发环境。

Kubernetes原生

尽管不特定于Kubernetes，但该机制是Kubernetes工作方式的本机。 它使用内置的秘密机制，无需任何第三方工具即可使用。 它适用于任何Kubernetes发行版，如果您已经了解Kubernetes机密的工作原理，那么直接了解它的工作原理是很简单的。

没有供应商锁定

这还提供了一种供应商中立的方式来轮换和使用证书。 今天，例如，如果使用HashiCorp Vault，则需要在代码中使用Vault客户端连接到Vault服务器以获取密钥，从而将您的代码与Vault绑定。 该约定允许将管理密钥的任何事物与使用者分离。 这在开发和测试环境中也可能是有利的，例如，由于许可或成本原因，您可能无法在本地计算机上运行供应商机密管理器，因此您可以在这些环境中替换为其他设备。

缺点

当然，公约并非没有弊端。

依赖文件系统

某些人可能会反对使用文件系统来分发机密，而宁愿仅通过经过身份验证的连接来传递机密。 当然，有时需要将一些机密传递给代码–如果代码要通过第三方机密管理器进行身份验证以检索机密，则用于身份验证的机密需要存储在某个位置，例如文件系统或环境变量。

信赖或Kubernetes的秘密

有些人可能会担心Kubernetes自身存储秘密的方式。 据我了解，我认为它要么是可插入的，要么可以被加密的（例如，我知道GKE支持与Cloud KMS集成以加密Kubernetes存储的秘密）。 但是在某些情况下，这对于人们来说可能不够好。

更改代码使用机密的方式

从文件系统读取机密的要求可能会破坏通常会消耗配置文件或环境变量的机密的库。

结论

那么，这个约定听起来有用吗？ 如果您要添加任何内容，请发表评论！

翻译自: https://www.javacodegeeks.com/2020/03/rotating-secrets-in-kubernetes.html

先旋转x在旋转y 在旋转z