从网络策略到安全策略

[caicloud2015]

Kubernetes 网络策略

Kubernetes 支持网络策略的新 API ，为隔离应用和减少攻击层面提供复杂的模型。这个功能由 SIG － Network group 演化而来，可以通过内置标签和 Kubernetes 创建的选择器，令定义网络策略变得轻松、优雅。

Kubernetes 将这个功能留给到第三方来实施这些网络策略，同时不需要提供默认实现。

我们希望引入一种新的方法来思考“安全”、“网络策略”。要说明的是，安全和可达性是两个不同的问题：将 Pod 识别和策略定义转换成网络约束，比如 IP 地址、子网如此之类的。

然而，我们也从过去的经验中知道，使用外部控制面板也可以引入新的挑战： ACL 的发行版本要求 Kubernetes workers 之间较高的同步性； 每当创建一个新的 Pod ，其余 Pod 上的 ACL 都需要进行更新，因为旧的 Pod 上面更新的 Pod 上的一些策略是相关的。当共享状态机制能够在小一些的规模中运行的时候，高度的相关性显然是二次问题，在大规模集群中，他们往往有汇聚性、安全性以及最终的一致性问题。

从网络策略到安全策略

在 Aporeto ，我们使用不同的方法来实施网络策略，从策略那里解耦网络。我们将我们的解决方案开源为 Trireme ，旨在将网络策略转化为授权策略，为 Pod 之间的交流实施透明的身份验证和授权功能。相比于使用 ACL 或者滤包器来实施策略， Trireme 使用的是授权功能。在这样的功能之下，容器使用跟策略要求匹配的身份只需要收到容器发过来的流量。 Trireme 中，授权功能和验证功能都覆盖在 TCP 协调序列。身边识别（一整套标签）被俘获为一个 JWT ，由 local keys 标记，在 Syn/SynAck 协调中转换。收到的 worker 验证之后， JWT 被可信任授权机构（身份验证步骤）标记，并且验证接受链接策略的缓存文件。一旦接受连接，剩下通过 Linux 内核的流量，以及所有的保护策略有潜力提供服务（如果需要的话，也包括连接追踪功能）。目前的实施使用简单的用户空间程序，可以捕捉最开始的协商数据包，并且附加授权信息作为有效载荷。 JWT 包括在 Ack 数据包期间验证的 nonce ，还能够抵御中间人攻击、回方式攻击。

Trireme 实施直接跟 Kubernetes master 交流，不需要外部 controller ，在策略更新和 Pod 实例化的时候接收消息提示，这样的话就可以根据需要维护策略的本地缓存，更新授权规则。在需要同步的 Trireme 组件之间没有共享的状态。 Trireme 可以作为独立的进程在每个 worker 上部署，也可以在每个 worker 上使用 Daemon Sets 。在接下来的例子中， Kubernetes 拥有 Trireme Pod 的生命周期。

Trireme 的简化来源于安全策略与网络传输的分离。不考虑用来进行 Pod 交流的网络组合，策略实施直接跟连接上呈现的标签有关。这种身份识别给予运维人员极大的灵活性，即使没有将安全策略实施到网络实施细节，也可以使用任意网络组合。同样，联邦集群上的安全策略变得简单、可行。

Kubernetes 和 Trireme 部署

Kubernetes 弹性扩容、为容器部署和微服务提供可扩展的安全支持这些方面有着独一无二的地位。为实施这些策略， Trireme 提供简单、安全、可调度机制。

通过使用提供的 Daemon Set ，你可以尝试在 Kubernetes 上部署 Trireme 。你需要修改一些基于自己的集群架构的 YAML 参数。所有的步骤可以点击这里查看，文件中还包括了一个 3 层策略的例子，可以用来测试流量模式： https://github.com/aporeto-inc/trireme-kubernetes/tree/master/deployment 。

原文链接： http://blog.kubernetes.io/2016/12/from-network-policies-to-security-policies.html?utm_campaign=crowdfire&utm_content=crowdfire&utm_medium=social&utm_source=twitter

转载请联系我们