云原生时代，你的 Kubernetes 应用安全是否还需要 VPC 来保证？

本文主要是介绍云原生时代，你的 Kubernetes 应用安全是否还需要 VPC 来保证？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

公众号关注「奇妙的 Linux 世界」

设为「星标」，每天带你玩转 Linux ！

本文翻译自 2020 年的一篇英文文章 DO I REALLY NEED A VPC?^[1]。

由于译者水平有限，本文不免存在遗漏或错误之处。如有疑问，请查阅原文。

以下是译文。

从安全的角度来说，VPC 非但不是一种超能力，反而是另一层责任（another layer of responsibility）。

准备在 AWS 上部署应用？那你需要一个 VPC^[2]：这种虚拟私有网络（virtual private network）能够保护你的应用免受来自公网的攻击，就像它们部署在老式数据中心一样。这是“虚拟机为王” —— 即所谓的 Cloud 1.0 （IaaS 浪潮） —— 时代的指导哲学。

但如今，当我在云上构建新应用或与同行交流类似主题时，我们通常都不会提到 “VPC”。这是因为，人们越来越倾向于将云原生应用（cloud-native applications）直接部署在更高层的托管服务之上 —— 例如 Lambda、API Gateway 和 DynamoDB —— 这些服务通过 API 与彼此进行通信。在 AWS 上，这种情况下的最佳实践是 使用 IAM^[3] 做认证和鉴权，以保障微服务间的通信安全。

如果需要将公有云和私有数据中心打通，那 VPC 是不可或缺的。但**现代云原生应用的安全，真的还需要 VPC 扮演关键角色吗？**在给出我自己的答案之前，我先陈述几位业内专家的观点。

1. 需求分析：VPC 是可选还是必需？

也许此刻你正在与安全团队一起，评估你们为本地部署的应用（on-prem applications ）设计的云原生方案【译者注 1】。你们的评估方式是：对照一个清单（checklist），逐一检查方案是否满足其中列出的要求，满足的就打对勾（checking the box）。我们来听听 PurpleBox Security 公司的 Nihat Guven 对此怎么说：“安全（security）与合规（compliance）在其中同样重要，二者互相追赶（playing catch-up）”。但是，相比于真正去思考 VPC 能否提供安全优势、能提供哪些安全优势，“大家更多地将精力放在了合规方面，即 —— 遵循既有标准，只要清单上列出了（例如，VPC），我们就做”。

【译者注 1】

On-premises 表示部署在私有数据中心。这个词来源于单词 “premises”，注意这是一个独立的单词，并不是 “premise”（“前提、假设”）的复数形式（虽然 “premise” 的复数也是“premises”）。单词 “premises” 表示“（企业、机构的）营业场所”，由此引申出两个早期术语：

on-premises：本地机房
off-premises：非本地机房

到了云计算时代，公有云显然就是 off-premises 模式（不过没人这么叫）；与此相对应，on-premises 指没有部署在公有云上的，一般就是公司自己的数据中心，不管是自建的还是租赁的，也不管是自维护的还是托管的。On-premises 或 on-premises deployment 现在一般翻译为“本地部署”，虽然“本地”一词通常让人首先想到的是 “local”。

另一位 AWS hero Teri Radichel（即将出版的 *Cloud Security for Executives* 一书的作者）赞同这样一种观点：VPC 并没有什么神奇之处。“VPC 实际上并没有做任何事情”，她指出。“你真正需要的是一个包含 NACL、子网和安全组的合理网络架构。你需要知道如何构建这样的架构，然后才能针对攻击做好监控。此外，你还要理解网络的各个分层、攻击的种类，以及攻击者是如何渗透网络的。”

这引出了问题的关键所在：基于 IAM 的安全方案，其暴露面已经是理论上最小的；而为应用添加 VPC 这件事情，最终都会变成在这个最小暴露面之外，再加额外的防护层（ adding layers of security to the theoretical minimum imposed by IAM）。所以你引入 VPC 并不是为了解决某个问题，而是为了 —— 例如，增加额外的保护层防止数据渗透（ data exfiltration），或者能够对流量模式进行更细粒度的分析。

以上例子都说明，很多时候 VPC 只是可选项，而非必需。遗憾的是，很多工程师并没有理解到这一层。

2. 利弊权衡：额外的责任而非超能力

从安全的角度来说，VPC 非但不是一种超能力（superpower），反而是额外的责任（additional responsibility）。

“如果没有业务需求 —— 例如与私有数据中心互联 —— 那最好不要引入 VPC”，否则，“由于 VPC 而引入的额外复杂性对安全配置来说非但无益，反而有害”。– Don Magee，前 AWS 安全专家

确实，对于安全配置来说，越多并非永远意味着越好（more is not always better）。如果你连配置 IAM 角色都还没搞熟，那又如何相信你能做好 VPC 安全？如果你连 S3 bucket 的 public 属性都不清楚，那又如何确定你能管好安全组、ACL 以及 VPC 引入的 subnets？

VPC 确实会带来一些额外的网络监控工具，例如 flow logs，但问题又来了：你知道如何高效地使用这些工具吗？如果不知道，那就是在花大价钱抓数据，但又没有如何分析这些数据的清晰计划。

另外，并不是说引入了 VPC，它就自动为你的数据提供一层额外的防护。正如 Magee 提醒我们的：“即使在 VPC 内，数据的保护也仅仅 HTTPS 加密 —— 就像你自己用 HTTPS 加密一样。你觉得这种安全值得信赖吗？”。

3. 云原生安全：模型抽象与安全下沉

云安全太难了！但我显然不是在鼓励大家因此而放弃。相反，正是因为云安全如此困难且重要（both hard and important），我才建议你不要轻易引入自己的网络控制方案，而应该尽可能用好平台提供的安全能力。

这听起来像是 “serverless” 的套路 —— 事实上，我们确实离此不远了。毕竟，如 AWS Lambda 项目的创始人 Tim Wagner 所乐于指出^[4]的，所有 Lambda functions 默认都在 VPC 内运行 —— 这种 VPC 是 AWS 托管的，因此比大部分人自维护的 VPC 要更安全（我们得承认这个事实）。

这是目前大的技术趋势。AWS 仍然会维护主机层安全（host-level security），同时也会提供更上层的服务，例如 AppSync 和 DynamoDB。但我并不是说网络安全在这些领域已经式微了，而是说越来越多的职责下沉到了云提供商那里。你确实会失去一些控制能力 ，但换来的是 AWS 最佳实践的保驾护航之下，更快的应用构建速度。

你可能会说，保护云原生应用的安全其实最后就是：“要么裸奔，要么上云”（letting go and letting cloud）。确实，但这种职责模型转变（paradigm shift）是传统的安全团队才需要关心的^[5] ；对于用户来说，只需要用好这种优势，自然就会取得巨大收益。