TF+K8s部署指南丨利用TF防火墙策略实现Kubernetes网络策略（含映射表）

从5.0版本开始（版本更迭时间和具体内容），Tungsten Fabric支持使用防火墙安全策略框架实现Kubernetes 1.9.2网络策略。虽然Kubernetes网络策略也可以使用TF中的其它安全对象（如安全组和TF网络策略）来实现，但TF防火墙安全策略对标签的支持，有助于简化和抽象Kubernetes的工作负载。

TF防火墙安全策略可以实现路由与安全策略的解耦，并提供多维度分段和策略可移植性，同时显著提升用户可见性和分析功能。

另外，TF防火墙安全策略使用标签来实现不同实体之间的多维度流量分段，并具有安全功能。标签是与部署中不同实体相关联的键值对。标签可以是预先定义的，也可以是自定义的。

Kubernetes网络策略是有关如何允许Kubernetes工作负载的组（以下简称为pod）与其它网络端点相互通信的规范。网络策略资源使用标签来选择pod，并定义规则，这些规则规定了允许哪些流量进入所选的pod。

Kubernetes网络策略特性

Kubernetes网络策略具有以下特性：

·网络策略是特定于pod的，适用于一个pod或一组pod。如果指定的网络策略适用于一个pod，则到pod的流量由网络策略的规则决定。

·如果网络策略没有应用到pod，那么pod就会接受来自所有来源的流量。

·网络策略可以在ingress、egress或两个方向上为pod定义流量规则。如果没有明确指定方向，默认情况下，网络策略应用于ingress方向。

·当网络策略应用于pod时，该策略必须有明确的规则来指定ingress和egress方向的允许流量的允许列表。所有不符合允许列表规则的流量都会被拒绝和丢弃。

·可以在任何pod上应用多个网络策略。必须允许符合任何一个网络策略的流量通过。

·网络策略作用于连接而不是单个数据包。例如，如果从pod A到pod B的流量被配置的策略所允许，那么从pod B到pod A的该连接的返回数据包也是被允许的，即使已制定的策略不允许从pod B发起到pod A的连接。

·Ingress策略。Ingress规则由源的身份和允许转发到pod的源的流量的protocol:port类型组成。

源身份可以是以下类型：

·无类别域间路由（CIDR）块——如果源IP地址来自CIDR块，且流量符合protocol:port，那么流量将被转发到pod。

·Kubernetes命名空间——命名空间选择器标识命名空间，其pod可以将定义的protocol:port流量发送到ingress pod。

·Pod——Pod选择器标识网络策略所对应的命名空间中的pod，这些pod可以向ingress pod发送匹配的protocol:port流量。

·Egress策略。该策略指定了一个CIDR允许列表，允许特定protocol:port类型的流量从网络策略所针对的pod出发。

目的身份可以是以下类型：

·CIDR块——如果目标IP地址来自CIDR块，且流量符合protocol:port，那么流量将被转发到目的地址。

·Kubernetes命名空间——命名空间选择器标识命名空间，其pod可以将定义的protocol:port流量发送到egress pod。

·Pod——Pod选择器标识网络策略所对应的命名空间中的pod，这些pod可以从egress pod接收匹配的protocol:port流量。

将Kubernetes网络策略表示为 TF防火墙安全策略

Kubernetes和Tungsten Fabric防火墙策略在各自指定网络策略的语义上是不同的。通过TF防火墙策略高效实现Kubernetes网络策略的关键在于，在这两个实体之间映射相应的配置结构。

这些结构的映射关系如表1所示。

表1：Kubernetes网络策略和TF防火墙策略映射表

注意：创建Tungsten Fabric防火墙策略结构的项目是容纳Kubernetes集群的项目。例如，如果Kubernetes集群是独立集群，则在全局范围内创建TF防火墙策略结构，如果Kubernetes集群是嵌套集群，则在项目范围内创建TF防火墙策略结构。

解决Kubernetes网络策略标签问题

在TF防火墙策略中，pod的表示方式与相应的Kubernetes网络策略中的表示方式完全相同。TF防火墙策略处理的是Tungsten Fabric术语中的label或tag。TF不会将标签扩展到IP地址。

例如，在默认的命名空间中，如果网络policy-podSelector指定：role=db，那么对应的防火墙规则指定pod为（role=db && namespace=default）。不对pod IP地址或其它做翻译。

如果同一个网络策略也有namespaceSelector为namespace=myproject，那么对应的防火墙规则将该命名空间表示为（namespace=myproject）。不做其它翻译，也不做其它规则表示"myproject"命名空间的pod。

同样，每个CIDR由一个规则来代表。实质上，Kubernetes网络策略被1:1翻译成TF防火墙策略。只有一个额外的防火墙规则为每个Kubernetes网络策略创建。该规则的目的是实现网络策略的隐性拒绝要求，没有其它规则产生。

TF防火墙策略命名公约

Tungsten Fabric防火墙安全策略和规则命名如下：

·为Kubernetes网络策略创建的TF防火墙安全策略以如下格式命名：

< Namespace-name >-< Network Policy Name >

例如，命名空间"Hello"中的网络策略"world"：

Hello-world

·为Kubernetes网络策略创建的TF防火墙规则按以下格式命名：

< Namespace-name >-<PolicyType>-< Network Policy Name >-<Index of from/to blocks>-<selector type>-<rule-index>-<svc/port index>

例如：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: world
  namespace: hello
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend

与该策略对应的规则被命名为：

hello-ingress-world-0-podSelector-0-0

Kubernetes网络策略的实现

contrail-kube-manager daemon将Kubernetes和Tungsten Fabric绑定在一起。这个daemon 连接到Kubernetes集群的API服务器，并将Kubernetes事件（包括网络策略事件）覆盖到适当的TF对象中。对于Kubernetes网络策略，contrail-ke-manager执行以下操作：

·为每个Kubernetes标签（tag）创建一个TF标签（label）。

·为每个Kubernetes网络策略创建一个防火墙策略。

·创建一个应用策略集（APS）来表示该集群。在该集群中创建的所有防火墙策略都会附加到该应用策略集。

·对现有Kubernetes网络策略的修改会导致相应的防火墙策略被更新。

网络策略配置示例

下面的例子演示了在各种场景下网络策略和相应防火墙安全策略的创建。

例1 - 有条件的egress和ingress流量

以下策略指定了一个网络策略示例，其中包含了一个命名空间中所有 pod 的ingress和egress流量的特定条件。

Kubernetes网络策略示例

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 17x.xx.0.0/16
        except:
        - 17x.xx.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

TF防火墙安全策略示例

在Kubernetes中定义的test-network-policy会导致在Tungsten Fabric中创建以下对象。

1、标签tag

如果以下标签不存在，则会创建它们。在常规工作流中，这些标签必须在创建命名空间和pod时就已创建。

2、地址组

创建以下地址组：

3、防火墙规则

创建以下防火墙规则：

4、防火墙策略

以下防火墙安全策略的创建规则如下：

例2 - 允许所有Ingress流量

以下策略明确允许一个命名空间中的所有pod的所有流量：

Kubernetes网络策略示例

apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: allow-all-ingress
   spec:
     podSelector:
     ingress:
     - {}

Tungsten Fabric防火墙安全策略示例

1、标签Tag

如果以下标签不存在，则会创建它们。在常规工作流程中，这些标签会在创建命名空间和pod之前创建。

2、地址组 - 无

3、防火墙规则

创建以下防火墙规则：

4、防火墙策略

创建以下防火墙策略：

例3 - 拒绝所有ingress流量

下面的策略明确拒绝所有命名空间中的所有pod的ingress流量。

Kubernetes网络策略示例

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-ingress
spec:
  podSelector:
  policyTypes:
  - Ingress

Tungsten Fabric防火墙安全策略示例

1、标签tag

如果以下标签不存在，则会创建它们。在常规工作流程中，这些标签会在创建命名空间和pod之前创建。

2、地址组 - 无

3、防火墙规则 - 无

注意：任何网络策略的隐性行为都是拒绝不符合显性允许流的相应流量。但是在这个策略中，没有明确的允许规则。因此，没有为该策略创建防火墙规则。

4、防火墙策略

创建以下防火墙策略：

例4 - 允许所有egress流量

以下策略明确允许来自命名空间中所有pod的所有egress流量。

Kubernetes网络策略示例

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress
spec:
  podSelector:
  egress:
  - {}

Tungsten Fabric防火墙安全策略示例

1、标签tag

如果以下标签不存在，则会创建它们。在常规工作流程中，这些标签是在创建命名空间和pod之前创建的。

2、地址组 - 无

3、防火墙规则

创建以下防火墙规则：

4、防火墙策略

创建以下防火墙策略：

例5 - 默认拒绝所有egress流量

以下策略明确拒绝来自命名空间中所有pod的所有egress流量。

Kubernetes网络策略示例

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress

Tungsten Fabric防火墙安全策略示例

1、标签tag

如果以下标签不存在，则会创建它们。在常规工作流程中，这些标签是在创建命名空间和 pod 之前创建的。

2、地址组 - 无

3、防火墙规则 - 无

注意：任何具有egress策略类型的网络策略的隐性行为都是拒绝不匹配显性egress允许流的相应流量。在此策略中，没有明确的egress允许规则。因此，不会为该策略创建防火墙规则。

4、防火墙策略

创建以下防火墙策略：

例6 - 默认拒绝所有ingress和egress流量

以下策略明确拒绝了该命名空间中所有 pod 的所有ingress和egress流量。

Kubernetes网络策略示例

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress-egress
spec:
  podSelector:
  policyTypes:
  - Ingress
  - Egress

Tungsten Fabric防火墙安全策略示例

1、标签tag

如果以下标签不存在，则会创建它们。在常规工作流中，这些标签是在创建命名空间和pod之前创建的。

2、地址组 - 无

3、防火墙规则 - 无

注意：任何具有ingress/egress策略类型的网络策略的隐性行为都是拒绝不匹配显性允许流的相应流量。在此策略中，没有明确的允许规则。因此，不会为该策略创建防火墙规则。

4、防火墙策略

创建以下防火墙策略：

集群范围策略动作执行

网络策略的规范和语法允许最大的灵活性和各种组合。但是，在配置网络策略时必须小心谨慎。

接下来考虑一种情况，即创建两个网络策略：

·策略1：Pod A可以发到Pod B。

·策略2：Pod B只能从Pod C接收。

从网络流量的角度来看，上述策略之间存在着内在的矛盾。策略1规定，允许从Pod A流向Pod B。策略2意味着不允许从Pod A流向Pod B。从网络的角度来看，Tungsten Fabric优先考虑流量行为，认为其更为关键。在网络策略内在矛盾的情况下，Tungsten Fabric将尊重流量的视角。这个概念的核心之一是，如果一个策略与流量相匹配，那么这个行为将在整个集群范围内得到尊重。

例如，如果一个流在源端匹配一个策略，那么该流在目的端也会匹配相同的策略。因此，Tungsten Fabric管理的Kubernetes集群中的流的行为，如下图所示：

·允许从Pod A舱流向Pod B（由于策略1）。

·允许从Pod C舱流向Pod B（由于策略2）。

·任何其它流向Pod B的流量都是不允许的（由于策略2）。

网络策略动作执行场景示例

考虑以下网络策略动作执行的例子：

·允许所有egress流量，拒绝所有ingress流量。

设置：命名空间NS1有两个pod，Pod A和Pod B。

策略：在命名空间NS1上应用的网络政策规定：

·规则1：允许NS1中所有pod的所有egress流量

·规则2：拒绝NS1中所有pod的所有ingress流量

行为：

·Pod A可以向Pod B发送流量（由于规则1）

·Pod B可以向Pod A发送流量（由于规则1）

·来自不同命名空间的PodX不能向Pod A或Pod B发送流量（由于规则2）

·允许所有ingress流量，拒绝所有egress流量。

设置：命名空间NS1有两个pod，Pod A和Pod B。

策略：在命名空间NS1上应用的网络政策规定：

·规则1：允许NS1中所有pod的所有igress流量

·规则2：拒绝NS1的所有pod的所有egress流量

行为：

·Pod A可以向Pod B发送流量（由于规则1）

·Pod B可以向Pod A发送流量（由于规则1）

·Pod A和Pod B不能向任何其它命名空间的pod发送流量

·Egress CIDR规则

设置：命名空间NS1有两个pod，Pod A和Pod B。

策略：在命名空间NS1上应用的网络策略规定：

·策略1：允许Pod A向Pod B的CIDR发送流量。

·策略2：拒绝NS1中所有pod的所有ingress流量。

行为：

·Pod A可以向Pod B发送流量（由于策略1）

·所有其它通往Pod A和Pod B的流量都被取消（由于策略2）

原文链接：https://www.juniper.net/documentation/en_US/contrail20/topics/concept/k8s-network-policy.html

（注：原文出现Contrail或Contrail networking的地方，本文都以Tungsten Fabric替代，绝大多数情况下两者功能一致。）