如何通过 Kubernetes 网络策略隔离 1500 个微服务

阅读数:66 2020 年 1 月 19 日 09:00

如何通过Kubernetes网络策略隔离1500个微服务

Monzo 安全团队撰文分享了他们实现 Kubernetes 网络策略的经历,该策略通过 Calico 的 API 为 1500 个微服务提供了隔离。

Monzo 是一家面向移动端的数字银行,它们在 AWS 上运行其核心基础设施。除了使用 Kubernetes 托管其微服务外,Monzo 还使用 Apache Cassandra 作为主要数据库,使用 Apache Kafka 进行消息传递,并使用 Go 实现了其大部分程序代码。Monzo 安全团队将采用零信任网络作为他们的目标之一。零信任平台的原则是,网络内外的任何一个实体都是不被信任的,要访问私有信息必须要经过验证。Monzo 后端的每个服务只允许访问一个经过预先批准的服务列表。Monzo 大约拥有 1500 个服务,超过 9300 个服务间的交互,这也让该任务变得非常困难。在构建了一个通过分析代码来派生策略的自定义工具集之后,Monzo 团队在 Kubernetes 上使用了针对 Calico 的网络策略来提供隔离。

团队首先通过隔离一个服务来测试他们的初步方案。他们编写了一个名为 rpcmap 的自定义工具,这个工具可以通过分析静态代码来发现服务之间的依赖关系。根据 Monzo 后端工程师 Jack Kleeman 的说法,他们在集成测试或运行时选择静态分析的方式而不是观察的方式,主要是因为:

Monzo 有很多代码路径,没有一个可以涵盖所有内容的集成测试。在运行时,某项服务很少被调用并不意味着它从不会被调用;一间银行可以有一些每年只运行一次的服务进程。

规则必须按照可管理和可读的方式存储,而且不能破坏现有的服务。Monzo 安全团队采用了 Kubernetes 的 NetworkPolicy 来执行规则探测,并使用 Calico 网络插件来实现网络策略。这种初始方法在可测试性方面非常脆弱,并把维护规则列表的责任交由管理调用服务的团队负责。另一个引入的缺点就是开发团队必须手动编辑 Kubernetes 的配置文件。

为解决这些问题,Kleeman 说:“跟 Calico 社区讨论了网络策略的测试问题后,我们发现可以使用 Calico 的一些无法被 Kubernetes 访问的特性来测试我们的策略。”其中的一个特性允许流量访问网络策略通常不允许的内容,随后记录下来这种情况。Kubernetes网络策略通常采用选择器和标签的方式,在没有采用任何策略的时候,Kubernetes 允许 pod 之间的所有通信。Monzo 将他们的策略配置在最后运行,并监控网络流量来确定哪些服务会丢失数据包。

此后,团队将服务允许的流量列表切换为调用服务的一个属性,而不是目标服务的属性。服务通过标签声明它们在策略的入口(ingress)规范中需要访问到的服务。针对那些调用大量其他服务的服务,例如监控服务,则会按照“服务类型”进行分组,按照这样的准则,就没有必要列出每个服务了。rpcmap 被配置为每次提交时运行,部署管道把规则文件转换为服务标签。团队计划在未来使用服务网格而不是 CNI(容器网络接口)层来实现这一点,他们已经迁移到了一个使用 Envy 的自定义网格。

原文链接:

How Monzo Isolated Their Microservices Using Kubernetes Network Policies

评论

发布