Tungsten Fabric与K8s集成指南丨创建安全策略



  • 作者:吴明秘

    Hi!欢迎来到Tungsten Fabric与Kubernetes集成指南系列,本文介绍如何创建安全策略。
    Tungsten Fabric与K8s集成指南系列文章,由TF中文社区为您呈现,旨在帮助大家了解Tungsten Fabric与K8s集成的基础知识。大家在相关部署中有什么经验,或者遇到的问题,欢迎与我们联系。
    

    安全策略可以通过限制端口、网络协议等方式控制任意pod之间的访问,以及pod与service之间的访问。在K8s集群中安全策略对应的是Network Policy,在Tungsten Fabric中安全策略对应的Firewall Rule,两者是会实时同步的。

    pod之间的访问控制

    安全策略的控制是全局的,跨命名空间,跨network,所以创建策略的时候要尽可能详细地指定此端到彼端的一些参数,包括端口、命名空间、IP地址段等等。

    根据第二章节的信息,可以知道目前有——

    两个命名空间:test-ns1 test-ns2

    三个network:k8s-ns1-pod-net01 k8s-ns1-pod-net02 k8s-ns2-pod-net01

    四个pod:
    nginx01-ns1-net01
    nginx01-ns1-net02
    nginx01-ns2-net01
    nginx02-ns2-net01

    而k8s-ns1-pod-net01与k8s-ns1-pod-net02已经互通(通过新建TF router连通),k8s-ns1-pod-net01 与k8s-ns2-pod-net01已经互通(通过TF Network Policy连通)。

    首先,新增一条默认禁止访问策略,禁止任何流量访问test-ns1的pod,配置如下:

    d8d5b283-b8c2-4ce9-b982-75782118497e-image.png

    #pod选择器设置为空,表示选择所有pod,即控制整个命名空间。
    #只写了ingress生效,又把podSelector设置为空,表示拒绝其它命名空间访问,拒绝所有入站请求。
    #没有加egress,所以默认egress是允许本命名空间所有pod出站。

    创建策略后,验证从test-ns2的k8s-ns2-pod-net01网络是否能访问到test-ns1的k8s-ns1-pod-net01网络。

    验证过程如下图所示,首先从test-ns2的pod去ping test-ns1的pod是可以通的,但是在创建了Network Policy之后,就无法ping通了,说明Network Policy限制了从其他地方的流量去访问test-ns1的pod,而即使是test-ns1内部的pod都无法相互访问。

    adc7fcfe-d919-40c1-967c-07bee41fa956-image.png

    而再Tungsten Fabric的管理界面上,会看到一条新的Firewall Rule:

    32688e0f-1441-4cd7-b188-86eca1761434-image.png

    然后,再新增一条安全策略,允许子网20.10.10.0/24里的pod访问test-ns1中有标签为nginx-ns1的pod的80端口(test-ns1中的两个pod均带有此标签),除了IP为20.10.10.3的pod,具体配置如下:

    dfa963af-bd19-40a4-a0a2-5b1eebfa9b48-image.png

    创建策略后,验证从test-ns2的pod是否能访问到test-ns1的pod的80端口。

    验证过程如下图所示,首先从test-ns2的两个pod(20.10.10.1和20.10.10.3)用curl去请求test-ns1 pod(10.10.10.1)的80端口,未新建安全策略前,curl请求均失败了。

    创建安全策略之后,只有pod(20.10.10.1)能成功请求pod(10.10.10.1),而pod(20.10.10.3)无法成功请求对应的80端口,说明新建的策略是正常生效的。

    7b65a9d5-c77c-4f46-8058-01141b12aa3b-image.png

    Tungsten Fabric上新建了三条对应的Firewall Rule,分别为:

    1.允许网段10.10.0/24的pod问test-ns1中带标签app=nginx-ns1的pod;
    2.禁止ip为10.10.3/32的pod访问test-ns1中带标签app=nginx-ns1的pod;
    3.禁止所有的pod访问test-ns1中带标签app=nginx-ns1的pod。

    三条规则组合后,就能实现我们预期的pod隔离效果。

    c895da7c-9e35-4126-b141-049e08e06cfa-image.png

    pod与service之间的访问控制

    K8s的service是一个抽象概念,定义了一个服务的多个pod逻辑合集和访问pod的策略,一般把service称为微服务。

    在此,首先在test-ns1和test-ns2中都各自新建一个service,配置如下:

    13f37a15-1b3d-470f-b71c-8004912f024a-image.png
    47451181-a688-4e84-8bb3-2becafe30794-image.png

    执行kubectl创建命令,两个service分别在test-ns1和test-ns2中被创建了出来,对应的在Tungsten Fabric的load balancing列表也会生成这两个service的信息。

    adb8508b-540a-47e1-99de-179506790138-image.png

    97cbf886-69fb-49ad-adeb-691205fd39a2-image.png

    4ea1d73e-9db1-4c20-a4b2-b2431a1dc9ad-image.png

    通过test-ns1的pod(10.10.10.1),可以使用curl直接请求service的域名。

    1144af95-72ae-4a83-bacf-bd1093654a0a-image.png

    现在通过新建一条K8s的Network Policy,去禁止test-ns1的pod(10.10.10.1)去访问test-ns2的service(nginx-ns2)。

    禁止test-ns1的pod(10.10.10.1)请求test-ns2的service(nginx-ns2)的ClusterIP(10.96.0.12),具体配置如下:

    7142ba1b-7309-4b79-b98a-53837af58d74-image.png

    验证流程:

    1.test-ns1的pod(10.10.1)在未创建网络策略deny-service-ip之前,能够通过curl成功请求test-ns2的service(nginx-ns2),能够通过nslookup成功请求到kube-system的service(kube-dns);

    2.在test-ns1命名空间中创建K8s的网络策略deny-service-ip;

    3.test-ns1的pod(10.10.1)在已创建deny-service-ip网络策略之后,不能够通过curl成功请求test-ns2的service(nginx-ns2),能够通过nslookup成功请求到kube-system的service(kube-dns)。

    所以网络策略deny-service-ip确实是禁止了test-ns1的pod(10.10.10.1),而不会影响它访问其他的service clusterip。

    724310f5-e97a-4c90-8743-5103bf9f8939-image.png

    (作者来自深圳市天源景云科技有限公司)

    “Tungsten Fabric+K8s集成指南”系列文章——

    第一篇:部署准备与初始状态
    第二篇:创建虚拟网络

    “Tungsten Fabric+K8s轻松上手”系列文章——

    第一篇:TF Carbide 评估指南--准备篇
    第二篇:通过Kubernetes的服务进行基本应用程序连接
    第三篇:通过Kubernetes Ingress进行高级外部应用程序连接
    第四篇:通过Kubernetes命名空间实现初步的应用程序隔离
    第五篇:通过Kubernetes网络策略进行应用程序微分段


Log in to reply