使用 External Secrets Operator 安全管理 Kubernetes Secrets

新钛云服已累计为您分享672篇技术干货

关键要点

· Kubernetes Secret 管理有助于将 Secret 与应用程序代码分离，并在需要时在集群中启用它们。

· 默认情况下，Secret 以不安全的 base64 形式存储，这是一种编码方法而不是加密。

· 第三方 Secret 管理系统是拥有集中、强大的 Secret 管理机制的更好的选择。

· ESO 是一个 Kubernetes Operator，它集成了外部 Secret 管理系统，例如 AWS Secrets Manager、HashiCorp Vault、Google Secret Manager、Azure Key Vault 等。

· External Secrets Operator 的目标是将来自外部 API 的 Secret 同步到 Kubernetes。

Kubernetes Secret 未加密地存储在 API 服务器的底层数据存储（etcd）中。任何拥有 API 访问权限的人都可以检索或修改 Secret，任何有权访问 etcd 的人也可以。Secret 对象类型用来保存敏感信息，例如密码、OAuth 令牌和 ssh key。

将这些信息放在 Secret 中比放在 pod 的定义中或者 docker 镜像中来说更加安全和灵活。然而，Kubernetes 尚不具备管理 Secret 生命周期的能力，因此有时我们需要外部系统来管理这些敏感信息。一旦我们需要管理的 Secret 信息量增加，我们可能需要额外的工具来简化和更好地管理流程。在本文中，我们将详细介绍其中一个工具 External Secrets Operator (https://external-secrets.io/)。

什么是Secret？

Secret 是用于管理用户到应用程序和应用程序到应用程序级别的访问权限的数字凭证。它们可以是密码、加密密钥、令牌等形式。

什么是Secrets Management？

Secret Management 是关于安全地管理数字凭证的创建、存储、轮换和撤销，同时消除或至少最大限度地减少人为参与并减少潜在的风险。

什么是 Kubernetes Secret？

容器需要访问敏感数据才能执行基本操作，例如与数据库、API 和其他系统集成。就 Kubernetes 而言，Secret 是一个包含数字凭证的对象，例如密码、令牌或密钥。使用Secret消除了将敏感信息存储在 pod 规范或容器映像中的需要。

问题

我们都知道使用 Secret 连接到外部服务的典型模式。下面是一个简单的解决方案架构，展示了我们如何使用 Secret 连接到数据库。

在这种情况下，我们有一个使用用户名和密码连接到数据库的微服务（或单体应用）。

当您开始支持多个环境（如开发、测试和生产）时，管理和同步所有这些 Secret 会变得有点困难。

现在，想象一下将您的应用程序拆分为多个服务，每个服务都有自己的外部依赖项，例如数据库、第三方 API 等，从而导致架构更加复杂。

具有多种服务和环境的设置（例如上述 Kubernetes 中的设置）会带来很多挑战，包括：

· 您可能需要管理数百个 Secret。

· 管理 Secret 的生命周期变得很困难，例如创建、存储、轮换和撤销。

· 加入新服务和具有特定访问权限的人员变得困难。

· 您必须考虑安全分发 Secret。

由于上述原因，您可以考虑选择第三方 Secret 管理工具来卸载与控制 Kubernetes Secret 相关的一些工作。

一些流行的工具和 Provider 可以实现更好的 Secret 安全性和可用性，如下所示：

· 云提供的工具：AWS Secrets Manager、Google Secret Manager、Azure Key Vault、IBM Cloud Secrets Manager、Oracle Key Vault

· 开源工具：HashiCorp Vault

因此，我们需要一个简单的解决方案，至少可以解决其中一些问题，它将存储在外部 Secret 管理工具中的 Secret 带入我们的集群，并继续在我们的应用程序中使用 Kubernetes Secret。这意味着我们需要一个组件来将外部 Secret 同步到我们的集群中。这就是 External Secrets Operator 为我们做的事情。

Operator设计模式

在我们仔细研究 External Secrets Operator (https://external-secrets.io/) 之前，让我们快速回顾一下Kubernetes Operators是什么。

我们已经知道，每个 Kubernetes 集群都有一个期望的状态。该状态决定了应该运行