云原生安全入门之k8s部分攻击面

点击蓝字 关注我们

之前一直在学习k8s的基本概念和基本用法，今天来学习一下k8s的未授权攻击面。今天的内容主要是因为运维配置不当造成的攻击面。

Kubernetes Api Server 未授权访问漏洞。

Kubernetes API服务器为API对象验证和配置数据，这些对象包含Pod，Service，ReplicationController等等。API Server提供REST操作以及前端到集群的共享状态，所有其他组件可以通过这些共享状态交互。默认情况，Kubernetes API Server提供HTTP的两个端口：8080，6443。insecure-port：默认端口8080，在HTTP中没有认证和授权检查。secure-port ：默认端口6443， 认证方式，令牌文件或者客户端证书。

当内容被更改为--insecure-port=8080

- --insecure-bind-address=0.0.0.0时，攻击者就可以通过ip地址+8080端口未授权访问api。

对于高版本，需要配合token才可以对pod进行操作，对于老版本的k8s,当出现上述配置时，可以直接通过kubectl进行操作。

此时，我们可以查看pod和node节点，同样的，也可以生成pod，并进入pod中执行命令。在挂载宿主机的根目录后，可以通过写计划任务之类的手法进行反弹shell，获得宿主机的权限。

kubelet未授权.

k8s node对外开启10250(kubelet API)和10255端口(readonly API)，攻击者可创建恶意pod或控制已有pod，后续可尝试逃逸至宿主机。

按照默认的配置，是不会产生漏洞的。当配置进行如下修改后，即可未授权访问api.

利用api获取的container,namespace,pod信息可以进入pod执行命令。

curl -XPOST -k "https://${IP_ADDRESS}:10250/run/<namespace>/<pod>/<container>" -d "cmd=<command-to-run>"

查看登录dashboard的命令

cmd=cat /var/run/secrets/kubernetes.io/serviceaccount/token

6443端口-system:anonymous错误配置

原来的6443端口是不能未授权访问的，但是如果将”system:anonymous”用户绑定到”cluster-admin”用户组，就会产生漏洞。

kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous。

k8s dashboard认证绕过（CVE-2018-18264）

攻击者可跳过登录，直接进入dashboard web页获取pod和job等状态，并可创建恶意pod，尝试逃逸至宿主机

修复建议:关闭dashboard的–enable-skip-login