码迷,mamicode.com
首页 > Web开发 > 详细

Tungsten Fabric+K8s轻松上手丨通过Kubernetes网络策略进行应用程序微分段

时间:2020-02-12 18:50:01      阅读:91      评论:0      收藏:0      [点我收藏+]

标签:oam   属性   --   兴趣   Kubernete   完整   中心   balance   创建   

点击下载文档,查看本文所有相关链接https://tungstenfabric.org.cn/assets/uploads/files/tf-ceg-case4.pdf

技术图片

在大多数生产环境中,需要实施网络访问控制。Kubernetes提供了一种方法来描述Pod 组应该如何通过使用NetworkPolicy资源进行通信。

与Kubernetes中的大多数事情一样,要使网络策略正常运行,您需要一个支持它们的Kubernetes CNI插件。

使用场景

在几乎所有环境中,为应用程序需要通信的组件建立明确的规则,都是一个好主意。Kubernetes网络策略规范是一种直接的方法,可让您将NetworkPolicy直接与应用程序清单集成在一起。

NetworkPolicy定义资源的方式,使您可以精确地指定哪些网络通信是被允许的,而哪些则不允许,同时使用podSelector定义处理在Kubernetes上运行的应用程序的动态属性。

这意味着您的策略可以针对单个Pod或Pod组,从而将安全范围“缩小”到Pod的大小。

严格定义的网络策略与default-deny配置相结合,可以避免由于恶意应用程序入 侵,和/或行为不当,或者配置错误而造成的麻烦。例如,一个应用程序组件可能具有滞留的缓存DNS条目或错误的配置参数,导致它与错误的后端进行通信。或者应用程序可能会被攻陷并被用作跳板,执行侦查,尝试横向渗 透,或者只是使用Pod对Kubernetes API的访问权限来启动一些加密货币挖矿Pod,以窃取您的计算资源。

使用网络策略保护示例应用程序的安全

网络策略设计的主题比本指南中允许的空间要大得多。在此示例中,我们将执行以下操作:

  • 为我们的default命名空间创建一个default-deny Ingress策略。这意味着命名空间内的所有传入Pods的连接必须明确被允许;
  • 为每个示例应用程序组件创建一个Ingress NetworkPolicy对象,仅允许那些我们确定的对象。

步骤1:明确哪些组件应当可以相互通信

首先,我们需要提醒自己,应用程序的各个组件应该如何通信。为此,我们将回到在简介中看到的应用程序图:

技术图片

从该图中可以看到:

  1. 外界需要到达yelb-ui的TCP端口80-(1)和(2)
  2. yelb-ui需要到达yelb-appserver的TCP端口4567
  3. yelb-appserver反过来将需要到达yelb-db的TCP端口5432,以及
  4. .. yelb-cache的TCP端口6379。

步骤2:如何识别组件?

请记住,NetworkPolicy资源使用选择器来识别策略适用于哪个Pod,以及该策略将要控制的流量的源和目的地是什么。

在本演示中,我们将使用podSelectror方法,因此需要获取应用到应用程序Pod的标签列表。让我们查看cnawebapp-loadbalancer.yaml示例应用程序的清单,并收集标签:
技术图片

现在准备编写我们的策略。

部署后,这些策略将以以下方式控制应用程序组件之间的通信:
技术图片

步骤3:“default-deny”策略

确保您位于沙箱控制节点上,以root用户身份登录,并且位于正确的目录中:

#确认您是root账户

whoami | grep root || sudo -s

#切换到清单目录

cd /home/centos/yelb/deployments/platformdeployment/Kubernetes/yaml

在此步骤中,我们将创建一个策略,该策略将阻止所有未明确允许的网络通信。在这一演示中,我们将只限制Ingress流量;但实际上,您也可以控制Egress流量(但是这样做时要注意这可能会阻止DNS查询!):

cat > yelb-policy.yaml <<EOF
# First, add Ingress default-deny
#
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: { }
  policyTypes:
  - Ingress
EOF

该策略基本上说:“对于任何Pod,都应用一个没有规则的Ingress策略”,这将导致应用这个策略的,所有流向这个命名空间Pods的传入流量被丢弃掉。

步骤4:“yelb-ui”的策略

该yelb-ui和其他组件在某种意义上说有一些不同,因为它是唯一一个可以被从外部访问的组件。因此,其ingress:定义将使用ipBlock的0.0.0.0/0,以表示“每个人”:

cat >> yelb-policy.yaml <<EOF
---
# Policy to let anyone reach yelb-ui
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: yelb-ui-in
spec:
  podSelector:
    matchLabels:
      app: yelb-ui
      tier: frontend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0
    ports:
    - protocol: TCP
      port: 80
EOF

该策略表示:“对于具有应用标签app: yelb-ui和tier: frontend的Pods,允许传入来自任何源IP的流量,只要它去往Pod的TCP端口80”。

步骤5:示例应用中其他Pod的策略

我们示例应用程序中的其他3个Pod仅会看到来自其他Pod的流量,因此其策略将使用带有允许发送流量的Pod标签的podSelector参数:

cat >> yelb-policy.yaml <<EOF
---
# Policy to let yelb-ui reach yelb-appserver
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: yelb-appserver-in
spec:
  podSelector:
    matchLabels:
      app: yelb-appserver
      tier: middletier
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: yelb-ui
          tier: frontend
    ports:
    - protocol: TCP
      port: 4567
---
# Policy to let yelb-appserver reach yelb-db
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: yelb-db-in
spec:
  podSelector:
    matchLabels:
        app: yelb-db
        tier: backenddb
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: yelb-appserver
          tier: middletier
    ports:
    - protocol: TCP
      port: 5432
---
# Policy to let yelb-appserver reach redis-server
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: redis-server-in
spec:
  podSelector:
    matchLabels:
        app: redis-server
        tier: cache
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: yelb-appserver
          tier: middletier
    ports:
    - protocol: TCP
      port: 6379
EOF

步骤6:在应用策略之前测试

为了能有一个“前后”对比,让我们部署示例应用程序并获取基线:

#部署我们的应用

kubectl create -f cnawebapp-loadbalancer.yaml

等待应用启动并在外部可用:

#获得我们程序yelb-ui Service的外部DNS名字:

kubectl get svc -o wide | grep yelb-ui | awk ‘{print $4}‘

我们应该可以看到类似a0b8dfc14916811e9b411026463a4a33-1258487840.us-west-1.elb.amazonaws.com的输出;在网络浏览器中打开它;样本应用程序应当加载了。

接下来,我们知道所有Pod通信都是不受限制的,因此我们应该能够从yelb-ui ping 到yelb-db——这是在应用程序正常运行且我们不进行故障排除动作的情况下,本来不应该发生的活动:

#获得"yelb-ui"的完整Pod名字

src_pod=$(kubectl get pods | grep yelb-ui | awk ‘{print $1}‘)

#获得"yelb-db"的IP:

db_pod_ip=$(kubectl get pods -o wide | grep yelb-db | awk ‘{print $6}‘)

#从"yelb-ui" ping"yelb-db":

kubectl exec -it ${src_pod} ping ${db_pod_ip}

我们应该看到该ping命令正在接收响应;因此存在不受限制的网络连接。按^ C停止命令。

步骤7:部署策略并测试结果

在最后一步,我们将部署策略并观察其效果:

#部署网络策略

kubectl create -f yelb-policy.yaml

运行上面的命令后,请等待几秒钟以稳定下来。Tungsten Fabric将在后台生成适当的安全组,并进行安装。让我们测试一下我们曾经可以正常运行的ping命令是否仍然有效:

#从"yelb-ui" ping "yelb-db" again:

kubectl exec -it ${src_pod} ping ${db_pod_ip}

这次,我们看到没有响应,因为该通信现在已被该策略阻止。接下来,测试是否仍可以通过网络浏览器访问该应用——应该可以!

步骤8:探索Tungsten Fabric的安全流量组可视化

Tungsten Fabric包含一个功能,可在“项目”中实现流量可视化,在我们的案例中,该项目对应于Kubernetes Namespace。

要访问它,请访问Carbide Evaluation Page链接,用于获取访问沙箱控制节点——在顶部有一个名为Contrail UI的链接,完成login和password的输入。单击链接,然后在左上角单击“Monitor”图标,然后在菜单中单击“Security” -> “Traffic Groups”。然后在顶部的标签链,在其末尾选择“k8s-default”:

技术图片

您应该看到类似于以下的图表:

技术图片
继续测试。您看到的流,代表示例应用程序在做的事情,包括无法从 yelb-uiping到yelb-db,以及yelb-appserver的出站请求(如果我们去查看,将转到yelb-db的DNS查询)。

清理

一旦进行了足够的探索,可以随时清理:

#卸载Network Policy

kubectl delete -f yelb-policy.yaml

#删除我们的示例应用程序:

kubectl delete -f cnawebapp-loadbalancer.yaml

#删除策略清单:

rm -f yelb-policy.yaml

回顾和资源

对于许多(即使不是全部)生产部署,控制应用程序的网络通信能力至关重要。在Kubernetes上运行的应用程序实现此类控件的方法是通过NetwokPolicy资源。但是,要使这些资源真正起作用,您需要一个支持它们的CNI插件。

Tungsten Fabric提供了完整的NetworkPolicy支持,无论集成Tungsten Fabric的Kubernetes在哪里运行,是在私有数据中心,还是在公共云中。

网络策略可以变得非常简单或非常复杂,而找出最适合您的应用程序的最佳方法,就是在我们提供的用例和示例基础上更深入地研究。这里有一些资源可能会有所帮助:

  • 网络策略的详细介绍
  • 一个不错的GitHub存储库,其中包含大量具有详细文档的网络策略清单示例
  • 在2019 Kubecon上的演讲中有一个介绍网络策略的很好的材料

(上述资源链接,可点击下载查看https://tungstenfabric.org.cn/assets/uploads/files/tf-ceg-case4.pdf)


至此,Tungsten Fabric Carbide指南文章系列文章告一段落,往期回顾——

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


【号外】TF中文社区3月Meetup活动,将聚焦Tungsten Fabric与K8s的集成,由重量级嘉宾分享Tungsten Fabric与K8s的部署和实践,详细演示操作过程,并解答关于Tungsten Fabric和K8s的一切问题。关注“TF中文社区”公众号,了解最新活动信息。


关于Tungsten Fabric:
Tungsten Fabric项目是一个开源项目协议,它基于标准协议开发,并且提供网络虚拟化和网络安全所必需的所有组件。项目的组件包括:SDN控制器,虚拟路由器,分析引擎,北向API的发布,硬件集成功能,云编排软件和广泛的REST API。
关于TF中文社区:
TF中文社区由中国的一群关注和热爱SDN的志愿者自发发起,有技术老鸟,市场老炮,也有行业专家,资深用户。将作为连接社区与中国的桥梁,传播资讯,提交问题,组织活动,联合一切对多云互联网络有兴趣的力量,切实解决云网络建设过程中遇到的问题。


技术图片
关注微信:TF中文社区
技术图片

Tungsten Fabric+K8s轻松上手丨通过Kubernetes网络策略进行应用程序微分段

标签:oam   属性   --   兴趣   Kubernete   完整   中心   balance   创建   

原文地址:https://blog.51cto.com/14638699/2470496

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!