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
评论