Kubernetes NetworkPolicy:打造更安全的容器运行环境

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 传统上,通常使用防火墙实现网络层的访问控制,比如iptables rule,部署应用之后,通过iptables设置运行的ip白名单。在使用Kubernetes之后,由于Pod是动态分配到机器上,而且在运行过程中随时可能迁移到其他机器,显然不适合继续使用手工配置iptables的方式。

常见的应用可以分为两大类:Job和Service。Job比较简单,就是一个普通的任务,完成之后就退出,一般不需要暴露对外服务的网络监听端口。Service是指长期运行的进程,监听某个网络端口,其他服务可以通过网络连过来。生产环境里,将服务暴露在网络上存在安全风险:必须限制只有信任的用户才能访问服务。我们肯定不希望未授权的用户能调用某个删除数据的接口,把DB里的数据删光。访问控制可以在应用层做,客户端访问服务时,带上身份校验信息,服务端校验客户身份,判断客户是否有权限完成请求的操作,如果有权限,执行客户端请求,否则返回一个拒绝信息。访问控制还可以在网络层做,只允许受信的网络段访问服务。两种方式各有优劣,应用层可以做到更细粒度的权限控制,但需要开发,并且要求能客户端/服务器在通信协议上支持鉴权。网络层鉴权不依赖具体应用,还有一个额外的好处是能防DDoS。今天的主题NetworkPolicy,就是一种网络层的访问控制机制。

传统上,通常使用防火墙实现网络层的访问控制,比如iptables rule,部署应用之后,通过iptables设置运行的ip白名单。在使用Kubernetes之后,由于Pod是动态分配到机器上,而且在运行过程中随时可能迁移到其他机器,显然不适合继续使用手工配置iptables的方式。好在Kubernetes考虑到这个需求,提供了Network Policy,通过Network Policy,我们不仅能限制哪些Pod能被哪些来源访问,甚至还能控制Pod能访问哪些外部服务。Kubernetes中的Network Policy只定义了规范,并没有提供实现,而是把实现留给了网络插件。阿里云容器服务的Terway支持Network Policy,接下来我们基于Terway介绍几个使用Network Policy的场景。

创建Terway集群

首先,我们要创建一个使用Terway的集群,也就是在创建集群的时候,网络插件选Terway。

Screen_Shot_2018_09_14_at_2_38_47_PM

等待一会,集群创建好。这是我刚刚创建好的集群,名字就叫terway

Screen_Shot_2018_09_14_at_2_39_35_PM

为了操作方便,我们直接用命令行的方式,先下载kubeconfig文件,保存到本地的$HOME/.kube/config

场景1: 限制服务只能被带有特定label的应用访问

首先部署一个nginx,两个实例,附带一个service

~ % kubectl run nginx --image=nginx
deployment.apps "nginx" created
~ % kubectl get pod
NAME                     READY     STATUS    RESTARTS   AGE
nginx-65899c769f-c9s8z   1/1       Running   0          24s
~ % kubectl expose deployment nginx --port=80
service "nginx" exposed
~ % kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   172.19.0.1      <none>        443/TCP   21h
nginx        ClusterIP   172.19.32.113   <none>        80/TCP    20s

现在,起一个新应用,访问刚刚创建nginx service

~ % kubectl run busybox --rm -ti --image=busybox /bin/sh

If you don't see a command prompt, try pressing enter.
/ # wget nginx
Connecting to nginx (172.19.32.113:80)
index.html           100% |***************************************************************************************************************************************************|   612  0:00:00 ETA
/ #

看上去没问题,网络是通的。接下来我们设置一个Network Policy,只允许带有label access=true的应用访问nginx,其他都不行。开一个新终端

~ % cat policy.yaml
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      run: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: "true"
~ % kubectl apply -f policy.yaml
networkpolicy.networking.k8s.io "access-nginx" created

回到运行busybox的终端,再执行一次wget nginx

/ # wget nginx
Connecting to nginx (172.19.32.113:80)

^C
/ #

可以看到,在设置完Policy之后,之前启动的busybox已经不能访问nginx了。我们重新启动一个带有label access=true的busybox

~ % kubectl run busybox --rm -ti --labels="access=true" --image=busybox /bin/sh
If you don't see a command prompt, try pressing enter.
/ # wget nginx
Connecting to nginx (172.19.32.113:80)
index.html           100% |***************************************************************************************************************************************************|   612  0:00:00 ETA
/ #

成功!

场景2: 限制能够访问暴露了公网SLB服务的来源IP

给上个场景中的nginx再创建一个LoadBalance类型的service,LoadBalance类型的service会创建一个SLB

~ % cat nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    run: nginx
  name: nginx-slb
spec:
  externalTrafficPolicy: Local
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: LoadBalancer
~ % kubectl apply -f nginx-service.yaml
service "nginx-slb" created
~ % kubectl get svc nginx-slb
NAME        TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
nginx-slb   LoadBalancer   172.19.89.136   47.95.180.200   80:31967/TCP   17s

我们创建了LoadBalance类型的service,SLB的IP是 47.95.180.200,先从本地请求一下试试:

~ % wget 47.95.180.200
--2018-09-14 08:07:23--  http://47.95.180.200/
Connecting to 47.95.180.200:80... ^C
~ %

网络不通,因为刚才我们设置了nginx只允许带有label access=true的应用访问,现在是我们从外部访问Kubernetes,根本不是Pod,更不要说设置label了。怎么办?

方案是修改之前创建的Network Policy,增加一个允许访问的来源IP段。把自己本地的IP地址加到白名单里去。先拿到自己的IP地址

~ % curl myip.ipip.net
当前 IP:1.2.3.4  来自于:中国 浙江 #我的实际IP不是这个,根据自己的实际情况处理。

然后编辑policy.yaml,把IP地址加进去。有些网络的出口IP有多个,所以这里加上了一个/24的段。100.64.0.0/10必须要带上,SLB健康检查地址在这个段里,不加上的话SLB健康检查会出错。

~ % cat policy.yaml
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      run: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: "true"
    - ipBlock:
        cidr: 100.64.0.0/10
    - ipBlock:
        cidr: 1.2.3.0/24
~ % kubectl apply -f policy.yaml
networkpolicy.networking.k8s.io "access-nginx" configured

好了,再访问一次

~ % wget 47.95.180.200
--2018-09-14 08:15:03--  http://47.95.180.200/
Connecting to 47.95.180.200:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 612 [text/html]
Saving to: 'index.html'

index.html                                       100%[=========================================================================================================>]     612  --.-KB/s    in 0s

2018-09-14 08:15:03 (67.6 MB/s) - 'index.html' saved [612/612]

网络又通了,完美!

场景3: 限制一个Pod只能访问www.aliyun.com

除了限制当前应用能被谁访问,有时候还要限制应用能访问谁,有时候我们要运行第三方应用,不希望这些应用访问到不该访问的网络。通过Network Policy,也能实现这个需求。

Network Policy只能通过IP地址配置规则,首先我们通过dig获取www.aliyun.com的地址

~ % dig +short www.aliyun.com
www-jp-de-intl-adns.aliyun.com.
www-jp-de-intl-adns.aliyun.com.gds.alibabadns.com.
v6wagbridge.aliyun.com.
v6wagbridge.aliyun.com.gds.alibabadns.com.
140.205.34.3
106.11.93.21
140.205.32.4
140.205.230.13

这样就拿到了域名解析到的IP列表。然后编写如下的Network Policy规则:

~ % cat busybox-policy.yaml
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: busybox-policy
spec:
  podSelector:
    matchLabels:
      run: busybox
  egress:
  - to:
    - ipBlock:
        cidr: 140.205.230.13/32
    - ipBlock:
        cidr: 140.205.34.3/32
    - ipBlock:
        cidr: 106.11.93.21/32
    - ipBlock:
        cidr: 140.205.32.4/32
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
    ports:
    - protocol: UDP
      port: 53

~ % kubectl apply -f busybox-policy.yaml
networkpolicy.networking.k8s.io "busybox-policy" configured

在这个规则里,我们配置了egress规则,也就是出网规则,限制应用对外访问。允许UDP请求,否则没法做DNS解析。

验证一下

~ % kubectl run busybox --rm -ti --image=busybox /bin/sh
If you don't see a command prompt, try pressing enter.
/ # wget www.aliyun.com
Connecting to www.aliyun.com (106.11.93.21:80)
Connecting to www.aliyun.com (140.205.230.13:443)
wget: note: TLS certificate validation not implemented
index.html           100% |***************************************************************************************************************************************************|  526k  0:00:00 ETA
/ #
相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
29天前
|
人工智能 弹性计算 运维
ACK Edge与IDC:高效容器网络通信新突破
本文介绍如何基于ACK Edge以及高效的容器网络插件管理IDC进行容器化。
|
1月前
|
监控 NoSQL 时序数据库
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
231 77
|
18天前
|
存储 Kubernetes 开发者
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
Docker 是一种开源的应用容器引擎,允许开发者将应用程序及其依赖打包成可移植的镜像,并在任何支持 Docker 的平台上运行。其核心概念包括镜像、容器和仓库。镜像是只读的文件系统,容器是镜像的运行实例,仓库用于存储和分发镜像。Kubernetes(k8s)则是容器集群管理系统,提供自动化部署、扩展和维护等功能,支持服务发现、负载均衡、自动伸缩等特性。两者结合使用,可以实现高效的容器化应用管理和运维。Docker 主要用于单主机上的容器管理,而 Kubernetes 则专注于跨多主机的容器编排与调度。尽管 k8s 逐渐减少了对 Docker 作为容器运行时的支持,但 Doc
95 5
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
|
2天前
|
Kubernetes Linux 虚拟化
入门级容器技术解析:Docker和K8s的区别与关系
本文介绍了容器技术的发展历程及其重要组成部分Docker和Kubernetes。从传统物理机到虚拟机,再到容器化,每一步都旨在更高效地利用服务器资源并简化应用部署。容器技术通过隔离环境、减少依赖冲突和提高可移植性,解决了传统部署方式中的诸多问题。Docker作为容器化平台,专注于创建和管理容器;而Kubernetes则是一个强大的容器编排系统,用于自动化部署、扩展和管理容器化应用。两者相辅相成,共同推动了现代云原生应用的快速发展。
28 10
|
30天前
|
人工智能 运维 监控
阿里云ACK容器服务生产级可观测体系建设实践
本文整理自2024云栖大会冯诗淳(花名:行疾)的演讲,介绍了阿里云容器服务团队在生产级可观测体系建设方面的实践。冯诗淳详细阐述了容器化架构带来的挑战及解决方案,强调了可观测性对于构建稳健运维体系的重要性。文中提到,阿里云作为亚洲唯一蝉联全球领导者的容器管理平台,其可观测能力在多项关键评测中表现优异,支持AI、容器网络、存储等多个场景的高级容器可观测能力。此外,还介绍了阿里云容器服务在多云管理、成本优化等方面的最新进展,以及即将推出的ACK AI助手2.0,旨在通过智能引擎和专家诊断经验,简化异常数据查找,缩短故障响应时间。
阿里云ACK容器服务生产级可观测体系建设实践
|
16天前
|
Prometheus Kubernetes 监控
OpenAI故障复盘 - 阿里云容器服务与可观测产品如何保障大规模K8s集群稳定性
聚焦近日OpenAI的大规模K8s集群故障,介绍阿里云容器服务与可观测团队在大规模K8s场景下我们的建设与沉淀。以及分享对类似故障问题的应对方案:包括在K8s和Prometheus的高可用架构设计方面、事前事后的稳定性保障体系方面。
|
8天前
|
监控 安全 Cloud Native
阿里云容器服务&云安全中心团队荣获信通院“云原生安全标杆案例”奖
2024年12月24日,阿里云容器服务团队与云安全中心团队获得中国信息通信研究院「云原生安全标杆案例」奖。
|
8天前
|
人工智能 运维 监控
容器服务Kubernetes场景下可观测体系生产级最佳实践
阿里云容器服务团队在2024年继续蝉联Gartner亚洲唯一全球领导者象限,其可观测体系是运维的核心能力之一。该体系涵盖重保运维、大规模集群稳定性、业务异常诊断等场景,特别是在AI和GPU场景下提供了全面的观测解决方案。通过Tracing、Metric和Log等技术,阿里云增强了对容器网络、存储及多集群架构的监控能力,帮助客户实现高效运维和成本优化。未来,结合AI助手,将进一步提升问题定位和解决效率,缩短MTTR,助力构建智能运维体系。
|
11天前
|
安全 虚拟化 异构计算
GPU安全容器面临的问题和挑战
本次分享由阿里云智能集团弹性计算高级技术专家李亮主讲,聚焦GPU安全容器面临的问题与挑战。内容分为五个部分:首先介绍GPU安全容器的背景及其优势;其次从安全、成本和性能三个维度探讨实践中遇到的问题及应对方案;最后分享GPU安全容器带状态迁移的技术路径与应用场景。在安全方面,重点解决GPU MMIO攻击问题;在成本上,优化虚拟化引入的内存开销;在性能上,提升P2P通信和GPU Direct的效率。带状态迁移则探讨了CRIU、Hibernate及VM迁移等技术的应用前景。
|
30天前
|
供应链 安全 Cloud Native
阿里云容器服务助力企业构建云原生软件供应链安全
本文基于2024云栖大会演讲,探讨了软件供应链攻击的快速增长趋势及对企业安全的挑战。文中介绍了如何利用阿里云容器服务ACK、ACR和ASM构建云原生软件供应链安全,涵盖容器镜像的可信生产、管理和分发,以及服务网格ASM实现应用无感的零信任安全,确保企业在软件开发和部署过程中的安全性。

热门文章

最新文章

相关产品

  • 容器服务Kubernetes版