云安全

什么是Kubernetes Kubernetes又名k8s，是一个由Google开源，现由 CNCF（云原生计算基金会）维护的容器编排平台 Kubernetes（K8s） 集群是k8s的基本运行单元，由一个控制平面和一组用于运行容器化应用的工作机器组成， 这些工作机器称作节点（Node）。每个集群至少需要一个工作节点来运行 Pod。 K8S集群主要负责容器编排，本质上来说，K8S不仅能将单个容器运行起来，将其对外暴露出去提供服务。还提供了：路由网关、集群监控、灾难恢复，以及应用的水平扩展等能力。 Kubernetes架构 从结构图不难看出，k8s主要是由Master节点（控制平面）以及工作器节点组成，Master节点参与对Node节点的管理控制 Master节点 MasterNode主要包括四个部分： ApiServer：顾名思义就是提供API接口进行资源操作，并提供认证、授权、访问控制、API 注册和发现等机制 Controller Manager：控制管理，负责维护集群的状态，监控各种资源状态的变化 Scheduler：调度程序，负责资源的调度，其实就是根据策略将Pod调度到相应的机器上 etcd：里面保存了整个集群的状态，用作 Kubernetes 所有集群数据的后台数据库。 Worker节点 WorkerNode主要有以下部分： pod：k8s的最小的调度和运行单元，一个pod可以包含一个或多个容器，pod内所有容器都共用一个IP地址和网络命名空间，其实就类似于一台机器以及机器上的进程服务 kubelet：每台节点上的代理，负责维护容器的生命周期 Kube-proxy：通过为Service资源的ClusterIP生成iptable或ipvs规则，实现将K8S内部的服务暴露到集群外面去；处理节点上的网络规则，让 Pod 之间能互相通信 k8s和docker，docker-compose的区别 最大的区别就是在于运行管理方面，doker和docker-compose更偏向于单机运行的管理，docker一次只能管理一个容器，虽然docker-compose能同时管理多个容器，但本质上还是只限制在一台机器中，而k8s是集群多机器编排，可以同时管理多台机器 除此之外，k8s还有以下特点： 弹性伸缩：容器数量的控制，流量高峰自动加副本，低谷自动缩减，节省成本 自我修复/高可用：对容器进行监测，如果某台机器宕机，Pod 自动迁移到其他机器，而出现问题的机器会自动抛弃或重启 自动部署和回滚：自动对容器的回滚更新且更新版本时无缝替换，用户无感知 k8s工作流程 k8s工作的时候通常会使用kubectl，kubectl 是 k8s 的客户端工具，可以使用命令行管理集群 具体流程如下： kubectl向apiserver发送部署创建请求（例如使用 kubectl create -f deployment.yml） apiserver将请求写入etcd，随后收到etcd的回调事件 apiserver将回调事件发送给ControllerManager，ControllerManager中的ReplicationController根据deployment的描述创建一个ReplicaSet并将ReplicaSet对象返回给apiserver并持久化回etcd Scheduler调度程序看到未调度的pod对象，根据调度规则选择一个可调度的节点，将节点名写入pod描述的nodeName字段中，并将pod对象返回给apiserver并写入etcd apiserver接收到etcd的回调后会将更新pod的事件发送给pod对应的node上的kubelet进程 kubelet在看到有pod对象中nodeName字段属于本节点，将其从队列中拉出，通过容器运行时创建pod中描述的容器 k8s安全基础 一方面是组件接口的安全风险： API server未授权访问 API server的默认服务接口是8080和6443，但是8080只提供http服务，并没有认证与授权机制，而6443两者兼并 默认情况下8080端口是不会启动的，但是如果使用者开启了该服务，就可能会造成API的未授权访问，从而控制整个k8s集群 使用kubectl获取集群信息 kubectl -s [ip]:[port] get nodes Kubelet未授权访问 Kubelet也是运行API服务的，默认服务端口是10250和10248，同样也容易存在未授权访问 etcd信息泄露 etcd默认监听2379（用于客户端连接）和2380（用于多个etcd之间的通信）端口 默认情况下，etcd两个端口的访问都需要证书去进行认证，所以如果我们拿到了证书或者使用者给etcd设置了允许匿名访问，那么就可以读取etcd中的数据，导致信息泄露风险 etcd v2：Kubernetes ≤ 1.5的版本默认使用etcd v2 /v2/keys/?recursive=true etcd v3：k8s v1.6开始默认使用 etcd v3,一般使用etcdctl实现对etcd的访问 文档：https://github.com/etcd-io/etcd/tree/main/etcdctl ...

前言 趁着这几天刚出完公司的题，抽出时间看了一下docker逃逸方面的东西，这里的话主要就是放攻击手法了，一些基础的概念就懒得赘述了 如何判断虚拟环境类型 参考：https://yuy0ung.github.io/blog/%E4%BA%91%E5%AE%89%E5%85%A8/%E8%AF%86%E5%88%AB%E8%99%9A%E6%8B%9F%E6%9C%BAdocker%E5%92%8Ck8s%E9%9B%86%E7%BE%A4%E7%8E%AF%E5%A2%83/ 通常在getshell之后，我们都需要考虑一个问题：我们是真的拿到目标机器的shell了还是只是处于机器中虚拟环境里？前者的话肯定直接做一些比如提权，内网穿透，横向移动，权限维持等内网渗透的手法，但是如果我们此时是处在机器中的虚拟环境中的话，我们需要先判断该虚拟环境的类型 通常情况下，shell的虚拟环境可能有三个类型：虚拟机，Docker，k8s。这三种类型对应着三种不同的攻击面： 虚拟机：通常考虑横向移动来扩大攻击效果 Docker：通常考虑容器逃逸到宿主机 K8s：通常先尝试接管集群，以获取对容器和集群资源的完全控制（注意：K8s其实本质上也是跑容器，只不过不一定用 Docker，现代 K8s 常见运行时是 containerd / cri-o） 当然，仍有一些特殊的情况比如：Docker运行在虚拟机里，这种情况在这里就不讲述了 查看主机名和进程 hostname #查看主机名 ps aux #显示系统上所有用户的详细进程信息 Docker 默认 hostname 通常是容器 ID 的前 12 位（不绝对），PID1非系统进程，可初步判断当前为容器环境 如果是在普通虚拟机或物理机里，PID 1 通常是：systemd 或者 init 如果是在容器里，PID 1 可能是： bash，sh，python，node，java，nginx，tini，supervisord 但是注意： 有些容器也会跑 systemd 有些轻量 VM 也可能不是 systemd 所以 PID 1 只是作为初步的判断 检查根目录下.dockerenv文件 ls -la /.dockerenv 通过判断根目录下的.dockerenv文件是否存在，确认当前环境是否为容器环境。 需要注意：有些 Docker 容器可能没有这个文件，甚至有些镜像为了伪装会删除掉这个文件 看 cgroup 信息 cat /proc/1/cgroup 或者： cat /proc/self/cgroup 这个文件是一个 内核提供的虚拟文件，里面包含了PID 1 这个进程属于哪些 cgroup，而cgroup 是 Linux 用来做资源隔离和限制的机制，通常用于限制一个进程/容器的cpu，内存等资源使用 ...