Contrail 防火墙策略

在第4章中，您可以 Contrail 对象映射图，此数字在此处按原样Figure 1重复。

Figure 1: Contrail Kubernetes 对象映射

此映射重点介绍’Kubernetes 核心对象的 Contrail 实施：命名空间、箱、服务、入口和网络策略。从第四章到7章，’我们对除网络策略之外Figure 1的所有内容都进行了充分研究。

在本章中，’我们将重点介绍 Contrail 中的网络策略实施。首先，’我们将介绍 Contrail 防火墙，这是用于实施 Kubernetes 网络策略的功能;然后，’我们将设置一个测试案例，验证 Kubernetes 网络策略如何在 Contrail 中工作。然后，根据测试结果，我们’会详细探讨 Contrail 防火墙策略及其规则，以便了解 Contrail 实施以及的Figure 1对象映射图中两个对象之间的映射。

Contrail 防火墙简介

第3章，我们推出了 Kubernetes 网络策略概念。我们详细经历了 YAML 文件定义，并创建了基于它的网络策略。我们’还提到，只要创建的网络策略对象’t 会产生任何影响，除非 Kubernetes 网络实施支持它。作为 Kubernetes CNI，Contrail 可实施 Kubernetes 网络，并通过 Contrail 防火墙支持 Kubernetes 网络策略。这是本章的重点-我们’将展示网络策略如何通过 Contrail 防火墙在 Contrail 环境中工作。

首先让’我们来回顾 Contrail 中的一些重要概念。

VN 间路由。

在 Contrail 中，虚拟网络默认情况下是孤立的。这意味着 VN1 中的工作负载无法与另一个 VN2 中的工作负载通信。要在 VN1 到 VN2 之间允许虚拟网络通信，需要 Contrail 网络策略。Contrail 网络策略还可通过允许或拒绝指定流量来提供两个虚拟网络之间的安全。

Contrail 网络策略。

Contrail 网络策略用于允许虚拟内部网络通信和修改虚拟网络流量。它描述了允许或不在虚拟网络之间的流量。默认情况下，如果没有 Contrail 网络策略，将允许虚拟内部网络通信，但是虚拟网络流量将被拒绝。创建网络策略时，必须将其与虚拟网络相关联，以使其生效。

安全组（SG）。

安全组（通常缩写为 SG）是一组规则，允许用户指定允许的或不允许通过端口的信息流类型。在虚拟网络中创建 VM 或 pod 时，在启动时可将 SG 与 VM 相关联。与 Contrail 网络策略（全局配置并与虚拟网络关联）不同，SG 基于每个端口进行配置，并将在与 VM 端口关联的特定 vRouter 流上生效。

Contrail 网络策略和 SG 的局限性

在现代 Contrail 云环境中，有时很难仅使用现有网络策略和安全组来实现所需的安全目标。例如，在云环境中，工作负载可能从一个服务器迁移到另一个，因此最有可能是 IP 经常变化的。只依靠 IP 地址来识别要保护的端点是令人头痛的。相反，用户必须利用应用程序级属性来操纵策略，这样，每次’工作负载和相关网络环境发生变化时，策略就无需更新。此外，在生产环境中，用户可能需要根据标记组合进行工作负载，这很难转换为网络策略或 SG 的现有语言。

Contrail 防火墙安全策略。

本章介绍另一项重要功能：Contrail 防火墙安全策略。

Contrail 防火墙安全策略允许从安全策略分离路由，vand 提供 multidimension 分段和策略可移植性，同时显著增强用户可见性和分析功能。

为了实施多维度信息流分段，Contrail 防火墙引入了标记的概念。标记是与部署中不同实体相关联的键值对。标记可以是预定义的或自定义的/用户定义的。Contrail 标记与 Kubernetes 标签十分相同。两者都用于识别对象和工作负载。您可以看到，这与 Kubernetes 网络策略设计类似，它也是 Contrail 使用其防火墙安全策略来实施 Kubernetes 网络策略的自然。在理论上，Contrail 网络策略或 SG 可以扩展以执行这项工作，但是通过 Contrail 防火墙支持标记可使其更简单

Contrail Kubernetes 网络策略用例

在本节中，我们’将创建用例，以验证 Kubernetes 网络策略在 Contrail 环境中的工作方式。首先’，我们要创建测试中所需的几个 Kubernetes 命名空间和箱。我们’将确认每个盒均可与 DUT 网络（受测设备）进行通信，因为默认的 "允许-任意-任意网络" 模式，然后创建网络策略并遵守相同信息流模式的任何更改。

• 网络设计

• 实验准备

• Kubernetes 网络策略创建之前的流量模式

网络设计

用例设计如Figure 2所示。

Figure 2: 网络策略测试案例设计

在Figure 2中，六个节点分布在三个部门中：开发、qa 和 jtac。Dev 部门正在运行数据库服务器（dbserver），以容纳从客户收集的所有重要数据。这种设计要求任何人都无法直接访问此 db 服务器，而只允许通过开发部门中的另一个 Apache 前端服务器访问数据库服务器，称为 web 开发。此外，出于安全考虑，只应将访问客户信息的权限授予授权客户端。例如，只有 jtac 部门的节点、dev 部门中的一个节点（名为 client1-dev）和源 IP 10.169.25.20 可以通过 web 访问数据库。最后，数据库服务器 dbserver 不应向其他节点发起任何连接。

实验准备

这是一个非常普通、简化的网络设计，您可以在任何位置看到。如果我们在 Kubernetes world 中对所有这些网络元素进行建模，则如Figure 3所示。

Figure 3: 网络策略：NS 和箱

箱我们需要创建以下资源：

• 三个命名空间：开发、qa、jtac

• 六个箱：

  • 两个服务器箱：web 还是开发，dbserver，开发

  • 同一命名空间中的两个客户端箱与服务器盒相同：client1-dev, client2-dev

  • 两个不同命名空间的客户端盒：客户端-qa，客户端-jtac

• 两个 CIDRs：

  • cidr 10.169.25.20/32，这是节点 cent222 的结构 IP

  • cidr 10.169.25.21/32，这是节点 cent333 的结构 IP

Table 1: Kubernetes 网络策略测试环境

版	pod	角色
主管	client1-dev	web 客户端
主管	client2-dev	web 客户端
qa	客户端-qa	web 客户端
jtac	客户端-jtac	web 客户端
主管	web 还是开发	web 服务客户端
主管	dbserver-开发	为 web 服务提供 dbserver

好的，’让我们来准备所需的 k8s 命名空间和箱资源，其中包含一个用于定义开发、qa 和 jtac 命名空间的一体化 YAML 文件：

Tip

理想情况下，每个盒应使用不同的图像运行。而且，web 服务器和数据库服务之间的 TCP 端口通常不同。在我们的案例中，为了简化测试，我们使用了我们’在整个书籍中为所有箱使用的完全相同的 contrail-web 服务器映像，使客户端到 web 的数据库服务器通信使用相同的端口号80。此外，我们还添加了一个标签：策略，以便显示此测试中使用的所有箱也更容易。

好了，现在创建所有资源：

Kubernetes 网络策略创建之前的流量模式

由于我们拥有所有的命名空间和机箱，因此在定义任何网络策略之前，’我要继续操作并在客户端和服务器之间发送流量。

当然，默认情况下，Kubernetes 网络遵循允许任意模式，因此我们期待在任何盒之间访问，这将是一种完全的网状访问关系。但请记住，此测试中的 DUT 是 web 1-dev，而 dbserver 是开发人员对观察的兴趣。为简化验证，根据我们的示意图，我们’专注于从客户端箱访问服务器箱，如图8.4 所示。

图8.4 的亮点是，所有客户端都可以按照允许任意模式访问服务器：

• 客户端与开发人员之间没有限制

• 客户端与 dbserver 网络开发箱之间没有限制

客户端与服务器之间的通信是双向和对称–的，因此每一端都可以启动会话或接受会话。它们分别映射到 Kubernetes 中的出口政策和入口策略。

Figure 4: 网络策略：创建网络策略之前的箱通信

显然，这些不能满足我们的设计目标，这正是我们为什么需要 Kubernetes 网络策略的原因，而’我们很快会有这部分。现在，让我们’快速验证 "允许-任意网络" 模式。

首先，’让我们验证在 web 服务器、开发人员和 dbserver 环境中的端口80上运行的 HTTP 服务器：

Note

如前所述，在此测试中，所有盒都具有相同的容器映像，因此所有盒都在其容器中运行相同的 web 还是相同应用程序。我们只需命名每个盒，即可在图中反映它们的不同角色。

现在，我们可以使用以下命令验证是否从其他盒访问此 HTTP 服务器。要测试入口流量：

这些命令将触发来自两个节点的所有客户端和主机的来自 web 开发人员箱的 HTTP 请求。-M5 卷曲命令选项可在响应超时前最长等待五秒，以便回应完成。如预期所示，所有访问都通过，然后返回与下一步相同的输出。

从 client1：

在此，w3m 获取卷曲的输出，返回一个网页 HTML 代码并将其呈现为可读文本，然后将其发送至 grep 以删除空行。要使该命令更短，您可以定义一个别名：

现在该命令看起来更短：

同样，您’将获得相同的测试结果，以便从任何其他箱访问 dbserver-开发。

创建 Kubernetes 网络策略

• client1-jtac 命名空间（即 jtac 开发的 pod）下的开发和箱可以访问 web 还是开发的 pod

• 允许通过 web 的开发使用的 pod （仅限）访问 dbserver-开发箱

• 所有其他客户端都不允许访问两个服务器箱

• 所有其他客户端都仍然可以相互通信

将这些要求转换为 Kubernetes 网络策略的语言后，’我们将与此网络策略 YAML 文件一起使用：

• 根据入口策略，以下客户端可以到达位于 dev 命名空间中的 web 服务-开发服务器箱：

  • client1-从开发命名空间开发

  • jtac 命名空间中的所有盒，均为设置中的客户端 jtac pod

  • 具有源 IP 10.169.25.20 的客户端（在我们的设置中为 cent222）

• 根据出口政策，dev 命名空间中的 web 服务开发服务器箱可以发起 TCP 会话面向 dbserver 开发箱，目标端口80用于访问数据。

• 对于目标 pod 服务器-dev，所有其他访问都将被拒绝。

• 所有其他盒之间的通信不受此网络策略影响。

让’我们创建策略并验证其效果：

后期 Kubernetes 网络策略创建

创建网络策略 policy1 后，让我们’测试从 pod client1-dev、客户端 jtac 和节点 cent222 主机访问 web 服务开发箱中的 HTTP 服务器：

从这两个机箱到 web 台开发的访问都很好，这正是我们所需要的。现在，如果从其他 pod 重复相同的测试 client2，客户端 qa 和另一个节点 cent333 现在已超时：

应用网络策略后的新测试结果如Figure 5所示。

Figure 5: 网络策略：应用 Policy1 后

网络策略对象的详细信息告诉相同的事项：

在上面的练习中，我们可以推断出 k8s 网络策略在 Contrail 中按预期方式工作。

但我们的测试尚未完成。在网络策略中，我们定义了入口和出口策略，但迄今为止，从 web 还是开发’的 pod 的’角度来看，我们仅测试 policy1 的入口策略是否成功工作。此外，我们还没有将任何策略应用于其他服务器箱，dbserver 开发。根据默认值允许任何策略，任何盒都无需问题即可直接访问。显然，这不是我们的原始设计所需要的。Dbserver 开发盒还需要另一个入口网络策略，最后，我们需要将出口政策应用于 dbserver，以确保其无法’连接到其他任何盒。我们需要确认至少要有三个测试项，即：

• 测试应用于 web 还是开发箱的 policy1 的出口政策;

• 为 dbserver-开发箱定义和测试入口策略;

• 定义并测试 dbserver 开发箱的出口政策。让’我们先来了解一下 policy1 的出口政策。

Web 还是开发箱上的出口政策

以下’是有关出口流量的测试：

结果显示，只有对 dbserver 的访问才会成功，而其他出口接入会超时：

Dbserver 上的网络策略-开发盒

目前为止，一切都好。让’我们来看一下第二个测试项，入口从其他盒中访问 dbserver 开发的 pod，而不是 web 程序-开发人员箱。测试出口流量：

所有箱均可直接访问 dbserver 开发箱：

我们的设计是阻止除 web 程序开发人员箱外的所有盒访问。对于这一点，我们需要应用其他策略。以下是第二个策略的 YAML 文件：

这种网络策略 policy2 与前一 policy1 非常相似，不同之处在于–策略类型仅在列表中有入口，因此只会定义入口策略。而入口策略只使用 podSelector 定义了一个白名单。在我们的测试案例中，只有一个 pod web 服务与开发人员具有匹配的标签，因此它将成为唯一一种允许在端口80上向目标 pod dbserver 开发的 TCP 连接。’立即创建策略 policy2，然后再次验证结果：

现在，对 dbserver-开发箱的访问是安全的！

Dbserver 上的出口政策-开发

好的，仅我们的设计目标就是最后一项要求：服务器 dbserver-dev 不应能够向其他节点发起任何连接。

当您查看 policy2 时，您可能想知道我们是如何实现这一目的的。在第3章中，我们强调网络策略仅基于白名单进行设计。因此，无论您在白名单中放置什么都意味着允许。只有黑名单给出了拒绝，但即使在黑名单中，您’也无法列出所有其他盒，仅是让其被拒绝。

• dbserver 上的 policy2-开发

• 全部拒绝 dbserver 开发

• 允许所有其他盒中的所有

看起来像我们在 dbserver 网络开发的出口政策中提供了空白名单，则不会被允许，并且所有目标箱的拒绝策略都将发挥作用。问题是，我们如何定义空白名单：

退出此’操作并不会按预期工作：

检查策略对象详细信息不会发现任何错误：

PolicyTypes 上存在问题。我们’并未在中添加出口，因此将忽略在出口策略中配置的任何内容。简单地在 policyTypes 中添加-出口会将其修复。此外，为了表达空白名单，出口：关键字是可选的，不是必需的。以下是新策略 YAML 文件：

立即删除旧 policy2 并应用此新策略。从 dbserver-dev 到任何其他盒（例如，pod client1-dev）的请求将被阻止：

这是说明了Figure 6中的网络策略测试结果的最终示意图。

Figure 6: 网络策略：在观察器-开发箱上应用空出口策略之后

流表中的放置操作

在结束测试之前，让’我们来观察 vRouter 在策略丢弃信息流时的信息流表。在节点 cent333 上，pod dbserver-dev 位于：

操作： D设置为 D （FwPolicy），表示由于防火墙策略而丢弃。与此同时，在另一个节点 cent222 （即 pod client1 开发的位置）中，我们’看不到任何生成的流量，表示数据包未到达：

Contrail 实施详细信息

我们’reiterated，Contrail 采用 Contrail 防火墙安全策略实施 Kubernetes 网络策略。您还知道，Kubernetes 标签在 Contrail 中公开为标记。这些标记由 Contrail 安全策略用于实施指定的 Kubernetes 策略。标记将从 Kubernetes 对象标签中自动创建，或在 UI 中手动创建。

在本节中，’我们将详细了解 Contrail 防火墙策略、策略规则和标记。具体而言，我们’将检查我们在上一节中创建和测试的 Kubernetes 对象与 Contrail 防火墙系统中相应 Contrail 对象之间的映射关系。

Contrail 防火墙采用以下层次结构设计：

• 顶层对象称为应用程序策略集，缩写为 AP。

• AP 具有防火墙策略。

• 防火墙策略具有防火墙规则。

• 防火墙规则具有端点。

• 可通过标记或地址组（CIDRs）识别端点。

Figure 7中说明了这一结构。

Figure 7: Contrail 防火墙

构建映射

Kubernetes 网络策略和 Contrail 防火墙策略是两个不同的实体，其中指定了各自的网络策略的语义。为了 Contrail 防火墙实施 Kubernetes 网络策略，Contrail 需要实施一对一映射，以实现从 Kubernetes 到 Contrail 防火墙的大量数据结构。这些数据结构是 Kubernetes 网络策略和相应 Contrail 防火墙策略的基本构建块。

Table 2列出了 Kubernetes 网络策略构造和 Contrail 中的相应结构：

Contrail-kube 管理器（公里）’在本书前面部分读过很多次，将在这两个领域之间进行所有的翻译。在 Kubernetes 网络策略的上下文中，基本上会发生以下情况：

1. KM 将在其 initialing 过程中创建 Kubernetes 群集名称的 AP。通常，默认 Kubernetes 群集名称为 k8s，因此您将在群集中看到具有相同名称的 AP。

2. KM 注册到 kube-apiserver 以观察网络策略事件。

3. 每当创建 Kubernetes 网络策略时，都将使用所有匹配的防火墙规则和网络端点创建相应的 Contrail 防火墙策略。

4. 对于在 Kubernetes 对象中创建的每个标签，将会创建相应的 Contrail 标记。

5. 根据标记，可以找到相应的 Contrail 对象（VN、箱、VMI、项目等）。

6. Contrail 随后会在 Contrail 对象的 AP 中应用 Contrail 防火墙策略和规则，这就是允许或拒绝特定信息流的方式。

AP 可与不同的 Contrail 对象相关联，例如：

• VMI （虚拟机接口）

• VM （虚拟机）或盒

• VN （虚拟网络）

• 项目

在 Contrail Kubernetes 集群中，AP 与虚拟网络相关联。每当在这些网络上传输流量时，将评估与 AP 相关的防火墙策略，并对流量采取相应的措施。

在上一节中，我们在用例中创建了两个 Kubernetes 网络策略。现在，’让我们来探讨为这些 Kubernetes 网络策略创建的 Contrail 对象。

应用程序策略集（AP）

如前所述，contrail-kube manager 将在初始化阶段使用 Kubernetes 群集名称创建一个接入点。第3章中介绍 Contrail 命名空间和隔离，我们发现，默认情况下，群集名称 k8s 在 Contrail 中。因此，AP 名称也将 k8s 在Figure 8所示的 Contrail 用户界面中。

Figure 8: Contrail UI：AP 配置 > Security > 全局策略 > 应用程序策略集

还有一个其他 AP 默认应用程序策略集，默认情况下创建。

策略

现在，单击防火墙策略以显示群集中的所有防火墙策略。在我们的测试环境中，您将发现以下策略可用：

• k8s-dev-policy1

• k8s-dev-policy2

• k8s-denyall

• k8s-allowall

• k8s-Ingress

Figure 9: Contrail UI：防火墙策略

Contrail 防火墙策略命名约定

K8s-policy1 和 k8s-policy2 策略是我们’创建的。虽然它们看起来与我们在 YAML 文件中提供的对象名称不同，但很容易分辨这一点。当 KM 基于 Kubernetes 网络策略创建 Contrail 防火墙策略时，它会在网络策略名称前面加上群集名称和命名空间的前缀：

这听起来应该很熟悉。以前，我们展示了在 YAML 文件中创建的 Kubernetes 虚拟网络对象名称之后，公里如何在 Contrail UI 中命名虚拟网络。

为入口 loadbalancer 创建 K8s 入口防火墙策略，以确保入口在 Contrail 中正常工作。详细说明超出了本书的范畴。

但更大的问题是，为什么我们在这里仍会看到两个更多防火墙策略，因为我们从未创建过像 allowall 或 denyall 这样的网络策略？

好的，请记住我们在第3章中推出 Kubernetes 网络策略，并提到 Kubernetes 网络策略使用白名单方法和隐式拒绝全部并允许所有策略？白名单方法的性质表示除白名单中添加的所有流量外，拒绝所有其他操作，而隐式允许所有行为将确保未参与任何网络策略的盒后端仍可继续其允许任何流量模式。有关此 implicitness 的 Contrail 防火墙的问题是默认情况下，它遵循拒绝所有模式-不显式定义的任何内容都将被阻止。这就是 Contrail 实施的原因，这两个相应的隐式网络策略由 KM 模块生成的两个显式策略接受。

此时可能会提出一个问题。有多个防火墙策略，应该先应用和评估哪一个，之后是哪些？换句话说，在哪个顺序 Contrail 应用和评估每个策略–具有不同顺序的防火墙策略评估将导致完全不同的结果。只需想像这两个序列 denyall-allowall 与 allowall-denyall。前者为所有其他箱提供了拒绝，而后者为序列号提供了答案。

序列号

评估 AP 中的防火墙策略时，必须按特定顺序评估。所有防火墙策略和所有防火墙规则（不久都将在这一过程中）都有一个序列号。如果存在匹配策略，则会执行此过程，并且评估将停止。它再次 contrail Kube 管理器，为所有防火墙策略和防火墙规则分配正确的序列号，使一切按正确顺序工作。无需手动干预即可自动完成此过程。’创建 Kubernetes 网络策略时，您无需担心这些事项。

我们’稍后将再次访问序列号，但现在让我们’来看一下防火墙策略中定义的规则。

防火墙策略规则

在下面的防火墙策略列表捕获中，您可以在右侧看到每个策略的规则数量。

Figure 10: Contrail UI：防火墙策略规则

K8s-policy1 策略有四个规则。单击规则将详细显示这些规则，如Figure 11中所示。

Figure 11: Contrail UI：k8s-policy1 规则

它看起来与我们’测试的 Kubernetes 网络策略 policy1 类似。让’我们将屏幕捕获中显示的规则放入Table 3中。

表8.2 的第一列是我们添加的规则编号;所有其他列都从 UI 屏幕截图导入。现在让’我们将其与 Kubernetes 对象信息进行比较：

我们在防火墙策略中看到的规则 k8s-policy1 与 Kubernetes 网络策略 policy1 中的规则相匹配。

K8s-denyall 防火墙策略中的规则

现在，’我们返回并检查 k8s-denyall 策略中针对我们的 Kubernetes 网络策略生成的规则。

Figure 12: Contrail UI：k8s-denyall 政策规则

同样，如果将其转换为表，如Table 4中所示。

K8s-alldeny 规则很简单。他们只是告诉 Contrail 拒绝与不在白名单中的其他所有盒的通信。值得一提的是，在应用程序 = web dev & & 命名空间 = dev）的方向上存在规则，因此，对于 web 的开发人员箱，将拒绝传出流量，而不存在这样的规则：应用程序 = dbserver-开发 & & 命名空间 = 环境中的任何一个。如果您在最后一节回顾我们的测试，在最初的策略 policy2 中，我们未在 policyTypes 中定义一个出口选项来拒绝 dbserver 开发的出口流量，这就是为什么在将此类规则翻译为 Contrail 防火墙时不会这样做的原因。如果我们将 policy2 更改为新策略 policy2-denyall 并检查相同，我们’将立即看到缺少的规则。

Figure 13: Contrail UI：k8s-denyall 规则

请注意，k8s-denyall 策略仅适用于网络策略选择的目标 pod –盒。在这种情况下，它仅适用于箱网络开发-dev 和 dbserver。其他箱，例如客户端-jtac 或客户端-qa 将不会受到影响。而这些盒将由 k8s-allowany 策略应用，我们’将在后面进行检查。

K8s-allowall 防火墙策略中的规则

在Figure 14中，k8s-allowall 策略似乎比其他策略具有更多规则。

Figure 14: Contrail UI：k8s-allowall 规则

尽管规则数量，但实际上 k8s-allowall 是最简单的一项。它在 NS 级别工作，每个 NS 仅有两个规则。在 UI 中，在搜索字段中，命名空间中的键作为过滤器，例如 dev 或 qa，您将’在Figure 15和Figure 16中看到这些结果。

Figure 15: Contrail UI：k8s-由 NS 开发人员过滤的 allowall 规则

Figure 16: Contrail UI：k8s-由 NS qa 筛选的 allowall 规则

此政策所说的是：对于尚未应用任何网络策略的那些盒式接下来，让’我们继续使用 Kubernetes 默认的 "允许任意网络" 模式并允许一切就绪！

序列号

在了解 Contrail 防火墙策略规则之后，让我们’回到序列号并准确了解其工作原理。

序列号是附加到所有防火墙策略的编号及其规则，用于确定应用和评估所有策略的顺序，并在某个特定策略中执行相同的工作。序列号越低，优先级越高。要查找序列号，您必须查看 Contrail 配置数据库中的防火墙策略和策略规则对象属性。

首先，’让我们浏览 ap 中的防火墙策略对象以检查其序列号。

Figure 17和Figure 18捕获防火墙策略中的序列号。

Figure 17: Contrail UI：策略的顺序编号：设置 > 配置编辑器

Figure 18: Contrail UI：政策的顺序编号（续）

我们’以前看到的所有五个策略都显示在这些屏幕截图的 ap k8s 下。例如，策略 k8s-policy1，它映射到我们明确定义的 Kubernetes 网络策略 policy1，以及策略 k8s-denyall，这是系统自动生成的内容。K8s-policy1 和 k8s-denyall 的图分别显示了序列号为00038.0 和00042.0。因此，k8s-policy1 具有更高的优先级，将首先应用和评估。这意味着，我们在白名单中定义的流量类型将先被拒绝，目标盒上的所有其他信息流都将被拒。这正是我们希望实现的实际目标。

Table 5中列出了所有防火墙策略的所有序列号，其最高优先级为最低：

根据序列号，应用程序和评估顺序是首个明确的策略，后跟 "拒绝所有策略"，最后是 "允许所有策略"。与 Kubernetes 中的顺序相同。

防火墙策略规则中的序列号

Figure 19: 规则 Contrail UI 序列号：设置 > 配置编辑器

如前所述，在同一防火墙策略中，还必须按特定顺序应用和评估策略规则。Contrail 防火墙中由序列号再次确保的。如Figure 19和Figure 20中显示了防火墙策略 k8s-policy1 规则中的序列号。

Figure 20: 规则 Contrail UI 序列号（续）

Table 6列出了防火墙策略 k8s-policy1 的所有规则的顺序编号，从最高优先到最低优先级。

让’我们与网络策略 YAML 文件配置相比较：

我们发现规则序列号与 YAML 文件中显示的顺序一致。换句话说，规则将按定义顺序应用和评估。

标签

我们’已经谈了 Contrail 标记，我们已经知道 Contrail kube 经理将每个 Kubernetes 标签都转换为一个 Contrail 标记，该标志连接到盒的相应端口，如Figure 21所示。

Figure 21: 标记 UI

UI 可视化

Contrail UI 提供了对安全性的理想可视化，如Figure 22所示。如果’您了解 Contrail 安全的工作原理，它就一目了然。

Figure 22: 具有工作负载的以上策略的示例信息流可视化

Figure 23: 采用更多网络策略的示例信息流可视化