本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
从网络策略到安全策略
Kubernetes 网络策略
Kubernetes 支持一种新的网络策略 API，该 API 提供了一个复杂的模型来隔离应用程序并减少其攻击面。此功能由 SIG-Network 小组开发，通过使用 Kubernetes 构建的内置标签和选择器，可以非常轻松优雅地定义网络策略。
Kubernetes 将这些网络策略的实现留给了第三方，并且没有提供默认实现。
我们希望引入一种思考“安全”和“网络策略”的新方式。我们希望表明安全性和可达性是两个不同的问题，并且使用端点（例如 Pod 标签）定义的安全策略不一定需要使用网络原语来实现。
我们 Aporeto 的大多数人都拥有网络/SDN 背景，我们知道如何使用传统的网络和防火墙来实现这些策略：将 Pod 身份和策略定义转换为网络限制，例如 IP 地址、子网等。
然而，我们也从过去的经验中了解到，使用外部控制平面也会带来一系列全新的挑战：ACL 的分发需要 Kubernetes 工作节点之间非常紧密的同步；每次实例化新的 Pod 时，都需要更新所有其他与新 Pod 有关的策略的 Pod 上的 ACL。非常紧密的同步从根本上来说是一个二次状态问题，虽然共享状态机制可以在较小规模下工作，但在大规模集群中通常存在收敛、安全和最终一致性问题。
从网络策略到安全策略
在 Aporeto，我们通过将网络与策略解耦，对网络策略执行采取了不同的方法。我们将我们的解决方案 Trireme 开源，它将网络策略转换为授权策略，并为 Pod 之间的任何通信实现透明的身份验证和授权功能。它不是使用 IP 地址来识别 Pod，而是为每个 Pod 定义一个经过加密签名的身份，即其关联标签的集合。它不是使用 ACL 或数据包过滤器来执行策略，而是使用授权功能，其中容器只能从身份与策略要求匹配的容器接收流量。
Trireme 中的身份验证和授权功能覆盖在 TCP 协商序列上。身份（即标签集）被捕获为 JSON Web Token (JWT)，由本地密钥签名，并在 Syn/SynAck 协商期间交换。接收工作节点验证 JWT 是否由受信任的机构签名（身份验证步骤），并根据策略的缓存副本验证连接是否可以接受。一旦连接被接受，其余流量将通过 Linux 内核流动，并受到它可能提供的所有保护（如果需要，包括 conntrack 功能）。当前的实现使用一个简单的用户空间进程，该进程捕获初始协商数据包并将授权信息作为有效负载附加。JWT 包含在 Ack 数据包期间验证的随机数，可以防御中间人或重放攻击。
Trireme 实现直接与 Kubernetes 主节点通信，无需外部控制器，并接收策略更新和 Pod 实例化通知，以便它可以维护策略的本地缓存并根据需要更新授权规则。Trireme 组件之间不需要任何需要同步的共享状态。Trireme 可以作为独立进程部署在每个工作节点中，也可以使用 Daemon Sets 部署。在后一种情况下，Kubernetes 负责 Trireme Pod 的生命周期。
Trireme 的简洁性源于将安全策略与网络传输分离。策略执行直接与连接上存在的标签相关联，而与用于 Pod 通信的网络方案无关。这种身份链接为操作员提供了巨大的灵活性，可以使用他们喜欢的任何网络方案，而无需将安全策略执行与网络实现细节绑定。此外，在联合集群中实施安全策略变得简单可行。
Kubernetes 和 Trireme 部署
Kubernetes 在其扩展能力和为容器和微服务部署提供可扩展安全支持方面是独一无二的。Trireme 提供了一种简单、安全且可扩展的机制来执行这些策略。
您可以使用提供的 Daemon Set 在 Kubernetes 之上部署和试用 Trireme。您需要根据集群架构修改一些 YAML 参数。所有步骤都在 部署 GitHub 文件夹 中详细描述。同一文件夹包含一个 3 层策略示例，您可以使用它来测试流量模式。
要了解更多信息、下载代码并参与项目，请访问