学习
实践
活动
专区
工具
TVP
写文章
专栏首页Tungsten Fabric中文社区TF+K8s部署指南丨利用TF防火墙策略实现Kubernetes网络策略(含映射表)
原创

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防火墙策略映射表

Kubernetes网络策略结构

TF防火墙策略结构

标签

自定义标签(每个标签一个)

命名空间

自定义标签(每个命名空间一个)

网络策略

防火墙策略(每个网络策略对应一个防火墙策略)

规则

防火墙规则(每个网络策略规则对应一条防火墙规则)

CIDR规则

地址组

集群

默认的应用策略设置

注意:创建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、地址组

创建以下地址组:

名称

前缀

17x.xx.1.0/24

17x.xx.1.0/24

17x.xx.0.0.0/16

17x.xx.0.0.0/16

10.0.0.0/24

10.0.0.0/24

3、防火墙规则

创建以下防火墙规则:

规则名称

动作

服务

端点1

Dir

端点2

匹配标签

default-ingress-test-network-policy-0-ipBlock-0-17x.xx.1.0/24-0

拒绝

tcp:6379

地址组:17x.xx.1.0/24

>

role=db && namespace=default

default-ingress-test-network-policy-0-ipBlock-0-cidr-17x.xx.0.0/16-0

通过

tcp:6379

地址组:17x.xx.0.0/16

>

role=db && namespace=default

default-ingress-test-network-policy-0-namespaceSelector-1-0

通过

tcp:6379

project=myproject

>

role=db && namespace=default

default-ingress-test-network-policy-0-podSelector-2-0

通过

tcp:6379

namespace=default && role=frontend

>

role=db && namespace=default

default-egress-test-network-policy-ipBlock-0-cidr-10.0.0.0/24-0

通过

tcp:5978

role=db && namespace=default

>

地址组:10.0.0.0/24

4、防火墙策略

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

名称

规则

default-test-network-policy

ldefault-ingress-test-network-policy-0-ipBlock-0-17x.xx.1.0/24-0 ldefault-ingress-test-network-policy-0-ipBlock-0-cidr-17x.xx.0.0/16-0 ldefault-ingress-test-network-policy-0-namespaceSelector-1-0 ldefault-ingress-test-network-policy-0-podSelector-2-0 ldefault-egress-test-network-policy-ipBlock-0-cidr-10.0.0.0/24-0

例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、防火墙规则

创建以下防火墙规则:

规则名称

行动

服务项目

端点1

Dir

端点2

匹配标签

default-ingress-allow-all-inress-0-allow-all-0。

通过

任何

任何

>

namespace=default

4、防火墙策略

创建以下防火墙策略:

名称

规则

default-allow-all-ingress

default-ingress-allow-all-inress-0-allow-all-0

例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、防火墙策略

创建以下防火墙策略:

名称

规则

default-deny-ingress

例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、防火墙规则

创建以下防火墙规则:

规则名称

行动

服务项目

端点1

Dir

端点2

匹配标签

default-egress-allow-all-egress-allow-all-0

通过

任何

namespace=default

>

任何

4、防火墙策略

创建以下防火墙策略:

名称

规则

default-allow-all-egress

default-egress-allow-all-egress-allow-all-0

例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、防火墙策略

创建以下防火墙策略:

名称

规则

default-deny-all-egress

例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、防火墙策略

创建以下防火墙策略:

名称

规则

default-deny-all-ingress-egress

集群范围策略动作执行

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

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

·策略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替代,绝大多数情况下两者功能一致。)

原创声明,本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

登录 后参与评论
0 条评论

相关文章

  • 杨雨:Tungsten Fabric如何增强Kubernetes的网络性能

    在混合多云的世界里,Kubernetes是如此流行,已经成为应用统一部署和管理的事实标准,而Tungsten Fabric与Kubernetes的集成,更增强了...

    Tungsten Fabric
  • DevSecOps集成CI/CD全介绍

    在了解 DevSecOps 之前,我们先来了解一下 DevOps 是什么。DevOps 是文化理念、实践和工具的结合,可提高组织高速交付应用程序和服务的能力。

    IT运维技术圈
  • Harbor在云原生联邦学习平台FATE中的应用

    作为云原生应用的必备组件, Harbor 已经在多个开源项目中得到集成和应用,本文介绍 Harbor 在联邦学习开源项目 FATE 及 KubeFATE 中的应...

    Henry Zhang
  • Tungsten Fabric入门宝典丨8个典型故障及排查Tips

    Tungsten Fabric入门宝典系列文章,来自技术大牛倾囊相授的实践经验,由TF中文社区为您编译呈现,旨在帮助新手深入理解TF的运行、安装、集成、调试等全...

    Tungsten Fabric
  • 一文掌握 Docker 技术体系

    ?点击“博文视点Broadview”,获取更多书讯 提起 Docker,很多软件工程师都会认为那是运维工程师需要掌握的技能。殊不知互联网日益内卷,极限环境下如...

    博文视点Broadview
  • K8s 系列(一) - 知识图谱

    Kubernetes(K8s) 作为当前最知名的容器编排工具,称得上是云原生(Cloud Native)时代的“操作系统”,熟悉和使用它是研发、运维、产品等的必...

    astraw99
  • 绿盟科技云安全纲领(下)

    绿盟科技自2012年开始研究并打造云计算安全解决方案,并于2022年正式推出“T-ONE云化战略”,将安全产品与方案全面向云转型,并构建开放的云化生态。本文将对...

    绿盟科技研究通讯
  • 从分层分区传统架构向云网架构转型 ——基于SDN的下一代金融云网络联合研究与应用实践

    编辑手记:金融云建设是一项技术集成创新、产业协同创新的重大、复杂性高的系统工程工作,金融机构技术研发应立足于金融科技核心,聚焦于SDN等技术应用之金融机构的特色...

    数据和云
  • 从重大漏洞应急看云原生架构下的安全建设与安全运营(下)

    前言 前一篇文章《从重大漏洞应急看云原生架构下的安全建设与安全运营(上)》中,我们简要分析了对于重大安全漏洞,在云原生架构下该如何快速进行应急和修复,以及云原生...

    腾讯云原生
  • K8s 很难么?带你从头到尾捋一遍,不信你学不会!

    虽然 Docker 已经很强大了,但是在实际使用上还是有诸多不便,比如集群管理、资源调度、文件管理等等。那么在这样一个百花齐放的容器时代涌现出了很多解决方案,比...

    民工哥
  • 最详细的 K8S 学习笔记总结(2021最新版)!建议收藏

    虽然 Docker 已经很强大了,但是在实际使用上还是有诸多不便,比如集群管理、资源调度、文件管理等等。那么在这样一个百花齐放的容器时代涌现出了很多解决方案,比...

    民工哥
  • 一文搞懂基于 Kubescape 进行 Kubernetes 安全加固

    Hello folks! 今天我们介绍一款开源容器平台安全扫描工具 - Kubescape。作为第一个用于测试 Kubernetes 集群是否遵循 NSA-CI...

    Luga Lee
  • 揭秘LOL背后的IT基础架构丨产品而非服务

    这个长系列的文章,探讨并记录了Riot Games如何开发、部署和运营后端基础架构的历程。我们是Riot 开发体验团队的软件架构师兼产品经理Nicolas Ti...

    Tungsten Fabric
  • 揭秘LOL背后的IT基础设施丨关键角色“调度”

    我们是Kyle Allan和Carl Quinn,在Riot的基础架构团队工作。欢迎阅读这个系列的第二篇文章,详细介绍我们如何在全球范围内部署和操作后端功能。在...

    Tungsten Fabric
  • IT运维面试问题总结-LVS、Keepalived、HAProxy、Kubernetes、OpenShift等

    etcd 是 CoreOS 团队发起的开源项目,是一个管理配置信息和服务发现(service discovery)的项目,它的目标是构建一个高可用的分布式键值(...

    杰哥的IT之旅
  • 你没见过的 K8S 大总结

    kubernetes 已经成为容器编排领域的王者,它是基于容器的集群编排引擎,具备扩展集群、滚动升级回滚、弹性伸缩、自动治愈、服务发现等多种特性能力。

    派大星在吗
  • 云原生安全白皮书中文版

    鸣谢中文译者:@rootsongjc、@N3erox0、@cafra、@aiaicaow、@hbrls、@losery、@knwng、@babysor、@gtb...

    CNCF
  • ubuntu 16.04部署kubernetes集群【详细教程】

    作为一名新时代的运维工程师,不掌握k8s这样开阔时代的工具怎能成为一名好运维呢?最近两周在折腾k8s集群,发现很是不容易。各种概念,各种插件。这里把安装过程和遇...

    学一学大数据
  • 《Scikit-Learn、Keras与TensorFlow机器学习实用指南(第二版)》第19章 规模化训练和部署TensorFlow模型

    有了能做出惊人预测的模型之后,要做什么呢?当然是部署生产了。这只要用模型运行一批数据就成,可能需要写一个脚本让模型每夜都跑着。但是,现实通常会更复杂。系统基础组...

    SeanCheney

扫码关注腾讯云开发者

领取腾讯云代金券