从网络策略到安全策略

编者注:今天的帖子是Aporeto的Kubernetes首席工程师Bernard Van De Walle,展示了他们如何采取新方法实施Kubernetes网络政策。

Kubernetes网络策略 

Kubernetes支持 网络政策的新API 提供了用于隔离应用程序并减少其攻击面的复杂模型。此功能是从 SIG网络集团通过使用内置的标签和选择器Kubernetes构造,可以非常轻松,优雅地定义网络策略。

Kubernetes留给第三方来实施这些网络策略,并且不提供默认实施。

我们想引入一种新的方式来考虑“安全性”和“网络策略”。我们想证明安全性和可达性是两个不同的问题,并且使用端点(例如,pod标签)定义的安全策略不需要特别使用网络原语来实现。

我们大多数人在 阿波莱托 来自网络/ SDN的背景,我们知道如何通过使用传统的网络和防火墙来实施这些策略:将Pod身份和策略定义转换为网络约束,例如IP地址,子网等。

但是,从过去的经验中我们也知道,使用外部控制平面还会带来一系列全新的挑战:ACL的这种分布要求Kubernetes工人之间非常紧密的同步;每次实例化新的Pod时,都需要对所有具有与该新Pod相关的策略的其他Pod进行ACL更新。从根本上说,非常紧密的同步是一个二次状态问题,尽管共享状态机制可以在较小的规模上发挥作用,但它们在大型集群中通常具有收敛性,安全性以及最终的一致性问题。 

从网络策略到安全策略

在Aporeto,我们通过实际将网络与策略脱钩,采取了另一种方法来实施网络策略。我们开源了我们的解决方案 Trireme,它将网络策略转换为授权策略,并为Pod之间的任何通信实现了透明的身份验证和授权功能。它没有使用IP地址来标识Pod,而是为每个Pod定义了一个经过密码签名的身份,作为其关联标签的集合。与其使用ACL或数据包过滤器来实施策略,不如使用授权功能,即容器只能从身份符合策略要求的容器接收流量。 

Trireme中的身份验证和授权功能覆盖在TCP协商序列上。身份(即一组标签)被捕获为JSON Web令牌(JWT),由本地密钥签名,并在Syn / SynAck协商期间进行交换。接收方验证JWT是否由受信任的权威机构签名(身份验证步骤),并针对该策略的缓存副本验证该连接可以接受。接受连接后,其余流量将流经Linux内核以及它可能提供的所有保护(如果需要,包括conntrack功能)。当前的实现使用一个简单的用户空间过程,该过程捕获初始协商数据包并将授权信息附加为有效负载。 JWT包括在Ack数据包中经过验证的随机数,可以防御中间人攻击或重放攻击。

Trireme实现无需外部控制器即可直接与Kubernetes主服务器通信,并接收有关策略更新和Pod实例化的通知,以便它可以维护策略的本地缓存并根据需要更新授权规则。不需要在Trireme组件之间共享任何状态,而这些状态需要同步。 Trireme可以作为独立进程部署在每个工作人员中,也可以通过使用 守护程序集。在后一种情况下,Kubernetes拥有Trireme Pod的生命周期。 

Trireme的简单性源自安全策略与网络传输的分离。策略执行直接链接到连接上存在的标签,而与用于使Pod通信的网络方案无关。这种身份链接为运营商提供了极大的灵活性,使他们可以使用他们喜欢的任何网络方案,而不必将安全策略的实施与网络实施细节联系在一起。同样,跨联合集群实施安全策略变得简单可行。

Kubernetes和Trireme部署

Kubernetes具有独特的扩展能力,并为容器和微服务的部署提供可扩展的安全支持。 Trireme提供了一种简单,安全且可扩展的机制来执行这些策略。 

您可以使用提供的Daemon Set在Kubernetes上部署并尝试Trireme。您需要根据您的集群体系结构修改一些YAML参数。所有步骤均在 部署GitHub文件夹。同一文件夹包含一个示例3层策略,可用于测试流量模式。

要了解更多信息,请下载代码并参与该项目,请访问:

-Kubernetes首席工程师Bernard Van De Walle 阿波莱托