生产 Kubernetes

第 7 章 秘密管理 秘密管理

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在任何应用程序栈中，我们几乎都会遇到秘密数据。这就是应用程序希望保密的数据。 通常，我们将秘密与凭证联系在一起。这些凭证通常用于访问集群内部或外部的系统，如数据库或消息队列。在使用私钥时，我们也会遇到秘密数据，因为私钥可能会支持我们的应用程序与其他应用程序执行相互 TLS 的能力。第 11 章将介绍此类问题。秘密的存在会带来许多运行方面的问题，，例如：

秘密轮换政策

在必须更改之前，秘密可以保留多久？

密钥（加密）轮换政策

假设秘密数据在持久化到磁盘之前是在应用层加密的，那么在加密密钥必须轮换之前，允许它存在多长时间？

秘密存储政策

存储秘密数据必须满足哪些要求？是否需要在隔离的硬件上持久保存秘密？是否需要将秘密管理解决方案与硬件安全模块（HSM）集成？

补救计划

如果秘密或加密密钥被泄露，您计划如何补救？您的计划或自动化能否在不影响应用程序的情况下运行？

一个好的起点是确定在哪一层为应用程序提供秘密管理。有些企业选择不在平台层面解决这个问题，而是希望应用团队动态地将秘密注入到他们的应用中。例如，如果企业正在运行一个秘密管理系统（如 Vault），应用程序就可以直接与应用程序接口（API）对话，以验证和检索秘密。 应用程序框架甚至可以提供直接与这些系统对话的库。例如，Spring 提供了 spring-vault 项目，用于对 Vault 进行身份验证、检索秘密并将其值直接注入 Java 类。虽然可以在应用层实现，但许多平台团队希望以平台服务的形式提供企业级的秘密功能，也许这样应用开发人员就不必关心秘密是如何到达的，或者在引擎盖下使用的是哪个外部提供商（如 Vault）。

在本章中，我们将深入探讨如何看待 Kubernetes 中的秘密数据。我们将从 Kubernetes 运行的底层开始，一直到 Kubernetes 向工作负载提供秘密数据的 API。就像本书中的许多主题一样，你会发现这些考虑因素和建议是有范围的--范围的一端包括相对于工程工作量和风险容忍度，你愿意达到的安全程度，另一端则侧重于你希望为使用该平台的开发人员提供什么级别的抽象。

纵深防御

保护我们的秘密数据在很大程度上取决于我们愿意在多大程度上保证其安全。 尽管我们想说我们总是选择最安全的方案，但实际情况是，我们会做出明智的决定，让我们 "足够安全"，并在理想情况下随着时间的推移不断加强这些决定。这伴随着风险和技术债务，是我们工作的精髓。然而，不可否认的是，对 "足够安全 "的错误判断会让我们迅速出名，而且不是好事。在下面的章节中，我们将探讨这些安全层级，并指出一些最关键的要点。

防御可以从物理层开始。 谷歌就是一个典型的例子。谷歌有多份白皮书，甚至还在YouTube 上发布了视频，介绍其数据中心安全方法。其中包括金属探测器、能拦截半挂卡车的车辆障碍物，以及仅为进入数据中心而设置的多层建筑安全防护。这种对细节的关注不仅仅局限于数据中心内的数据。当硬盘报废时，谷歌会让授权员工将数据清零，然后可能会将硬盘粉碎。虽然物理安全这个话题很有趣，但本书不会围绕数据中心的物理安全进行深入探讨，但云提供商为确保硬件安全所采取的措施令人惊叹，而这仅仅是个开始。

假设在磁盘被清零或粉碎之前，人类确实以某种方式访问了磁盘。大多数云提供商和数据中心通过确保硬盘在静态时加密来保护其物理磁盘。提供商可以使用自己的加密密钥和/或允许客户提供自己的密钥，这使得提供商几乎不可能访问您未加密的数据。这是纵深防御的完美范例。我们从物理角度对数据中心内部进行保护，并将其扩展到对物理磁盘上的数据进行加密，从而进一步杜绝了内部坏人对用户数据做任何事情的机会。 ...