本文超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。
从网络策略到安全策略
Kubernetes 网络策略
Kubernetes 支持一种用于网络策略的新 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 令牌 (JWT)，由本地密钥签名，并在 Syn/SynAck 协商期间交换。接收工作节点验证 JWT 是否由受信任的机构签名（身份验证步骤），并根据策略的缓存副本验证连接是否可以被接受。一旦连接被接受，其余的流量就会流经 Linux 内核及其可能提供的所有保护（如果需要，包括连接跟踪功能）。当前的实现使用一个简单的用户空间进程来捕获初始协商数据包，并将授权信息作为有效负载附加。JWT 包括在 Ack 数据包期间验证的随机数，可以抵御中间人攻击或重放攻击。
Trireme 实现直接与 Kubernetes 主节点通信，无需外部控制器，并接收有关策略更新和 Pod 实例化的通知，以便它可以维护策略的本地缓存并根据需要更新授权规则。Trireme 组件之间不需要同步任何共享状态。Trireme 可以作为独立进程部署在每个工作节点中，也可以使用守护进程集部署。在后一种情况下，Kubernetes 负责 Trireme Pod 的生命周期。
Trireme 的简洁性源于安全策略与网络传输的分离。策略的执行直接与连接上存在的标签相关联，而与用于使 Pod 通信的网络方案无关。这种身份链接使运营商能够非常灵活地使用他们喜欢的任何网络方案，而无需将安全策略的执行与网络实现细节联系起来。此外，跨联合集群的安全策略的实现变得简单可行。
Kubernetes 和 Trireme 部署
Kubernetes 的独特之处在于其扩展能力和为容器和微服务的部署提供可扩展的安全支持。Trireme 提供了一种简单、安全且可扩展的机制来执行这些策略。
您可以使用提供的守护进程集在 Kubernetes 之上部署和试用 Trireme。您需要根据您的集群架构修改一些 YAML 参数。所有步骤都在 部署 GitHub 文件夹中详细描述。同一个文件夹中包含一个您可以用来测试流量模式的 3 层策略示例。
要了解更多信息，下载代码并参与该项目，请访问