三七互娱技术团队

探寻容器安全隔离功能实现原理

点击上方蓝字关注我们

Image
01

背景

Image
Image

为保障k8s集群的安全性,我们购买了某云厂商的容器安全产品。其中有一项"隔离容器"功能是:假如某个pod有漏洞,被黑客入侵了,容器安全可以对其进行一键快速隔离,以阻止其向其他pod扩散或逃逸到node节点。本文的目的探寻容器安全隔离功能的实现原理并进行验证,从而进一步明确该功能在生产环境中对业务的影响。

02

操作界面

Image
Image
Image
Image
03

隔离原理

Image
Image

在容器net namespace 里增加iptables规则,拒绝所有流量。

~]# nsenter --net=/proc/$pid/ns/net  iptables -nLChain INPUT (policy ACCEPT)target     prot opt source               destinationtest-nips  all  --  0.0.0.0/0            0.0.0.0/0Chain FORWARD (policy ACCEPT)target     prot opt source               destinationChain OUTPUT (policy ACCEPT)target     prot opt source               destinationChain test-nips (1 references)target     prot opt source               destinationDROP all -- 0.0.0.0/0 0.0.0.0/0
04

目的

Image
Image

1.验证容器隔离的功能和效果;

2.明确该功能在生产环境中对业务的影响;

05

问题和结论

Image
Image
01.

隔离的效果是什么?

答:被隔离的pod内被所有的容器网络断开。。

02.

隔离原理是什么,通过什么技术手段进行隔离?

答:通过进入到pod net namespace 里增加iptables规则,拒绝所有流量。

03.

隔离容器之后,pod的表现是什么?

答:

表现1:pod内被隔离的容器网络被完全隔离,无法对外提供服务,也无法访问外部。

表现2:容器可能重启,取决于是否配置了livenessProbe.

情况①:容器没有配置livenessProbe,容器不会重启,只是网络被隔断。

情况②:容器配置了livenessProbe,kubelet对其探测会失败,容器会被不断进行重启。

04.

是否会重新拉起新的pod?

答:不会,因为pod总数没有变化。

05.

隔离容器之后是否对业务有影响?

答:可能会受影响。隔离之后容器无法正常工作,是否对业务造成影响取决于总的pod副本数和被隔离的容器数量。

          如果deployment 有多个pod副本,隔离了部分pod之后,仍能正常工作,则业务不受影响。

        如果deployment 仅有1个pod, 或虽然有多个pod副本,但隔离了之后,整个服务无法正常工作,则业务会受到影响。

06.

隔离之后能否保留现场?

答:同样,取决于是否配置了livenessProbe,如果没有配置了livenessProbe,容器不会重启,里面的所有文件都将保留。

如果配置了livenessProbe,容器会被重启,重启后是全新的容器,里面的所有文件无法保留。

06

测试和验证过程

Image
Image
01.

测试环境

启动一个的deployment,包含2个容器,其中1个容器配置的liveness。

Image

test-nginx.yaml

test-nginx.yaml---apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: nginx  name: nginxspec:  replicas: 2  selector:    matchLabels:      app: nginx  template:    metadata:      labels:        app: nginx    spec:      containers:      - image: nginx        name: nginx        livenessProbe:          tcpSocket:            port: 80      - image: centos:7        name: centos        command: ["/bin/sleep"]        args: ["600000"]
02.

开始验证

隔离之前

Image

执行kubectl apply -f test-nginx.yaml 之后,可以看到两个pod均正常运行。

Image

ssh到其中1个pod(第2个) 所在的node节点上可以看到运行了2个容器。

Image

检查和确认这2个容器共享同一个net namespace,其中31677是pause的pid

Image

隔离之前,进入31677的net namespace, 可以看到没有Iptables规则。

Image

隔离之后

Image

隔离之后,pod里的nginx容器因配置了liveness,在健康探测失败后触发了重启。

Image

进入centos容器,验证无法访问外部域名

Image

进入nginx容器,同样无法访问外部域名

Image

进入容器的31677的net namespace,检查iptables规则。存在一条拒绝所有的iptables规则。

~]# nsenter --net=/proc/31677/ns/net  iptables -nLChain INPUT (policy ACCEPT)target     prot opt source               destination**-nips  all  --  0.0.0.0/0            0.0.0.0/0Chain FORWARD (policy ACCEPT)target     prot opt source               destinationChain OUTPUT (policy ACCEPT)target     prot opt source               destinationChain **-nips (1 references)target     prot opt source               destinationDROP all -- 0.0.0.0/0 0.0.0.0/0

能否保留现场?

Image

同样,这取决于是否配置了livenessProbe,如果没有配置了livenessProbe,容器不会重启,里面的所有文件都将保留。

如果配置了livenessProbe,容器会被重启,重启后是全新的容器,里面的所有文件无法保留。

隔离之前,写入一个测试文件。

Image

隔离之后,因容器发生了重启,容器里没有保留上述测试文件。

Image

END

三七互娱技术团队

扫码关注 了解更多

Image