浅谈Kubernetes安全

admin

138876
文章

114
评论

2024年4月26日19:57:12评论12 views字数 4936阅读16分27秒阅读模式

点击蓝字关注我们

浅谈Kubernetes安全

随着云原生技术日益炽热，Kubernetes （简称K8s）已经是发展最快、市场占有率最高的容器编排引擎产品，鉴于其广泛的部署和关键作用，确保K8s环境的安全性显得至关重要。本篇文章将解读K8s的关键构成部分，阐明相关核心概念，并结合当前实际应用场景，揭示潜藏的安全隐患及常见威胁类型。

Kubernetes架构

直接进入正题，先抛一个详细的K8s概览图：

整体而言，Kubernetes（K8s）架构实质上可以归纳为三大关键模块：

1. Kubectl（user commands）：作为用户接口向K8s下发指令；

2. Master：作为K8s的大脑，对集群进行管理和控制，负责整个集群的决策、发现和响应集群事件；

3. Node：作为K8s集群的工作节点，在其之上运行着应用服务，而Node和Master之间通信是通过kubelet组件。

接下来让我们一同探究这三大关键模块的具体细节：

Kubectl

用户发送指令的接口。通过Api Server去调用各个进程来完成对Node的部署和控制。那么指令会存在哪儿呢？yaml文件中！通过yaml文件中的配置，kubectl会向master的Apiserver发起命令。

Master

作为K8s的大脑，包括了Apiserver、Controller Manager、Scheduler这三个大的模块。

Apiserver:

Apiserver作为一个数据交换的枢纽，功能是对核心对象的增删改查操作（如：Pod、Service、RC等）。ApiServer具体又分为以下几个部分：

- API层（主要以REST方式提供各种API接口）

- 访问控制层（负责身份鉴权、核准用户对资源的访问权限，设置访问逻辑）

- 注册表层（yaml文件中配置RC对应的需要生成的Pod个数，到了 Registry 层会从 CoreRegistry 资源中取出 1 个 Pod 作为要创建的 Kubernetes 资源对象；同时K8s集群会把所有的资源对象都保存在注册表中，如：Pod、service、deployment等）

- Etcd(主要是用作信息存储，存储资源信息。包括节点健康状况、节点资源、节点名称、节点地址信息、操作版本、Docekr版本、kubelet版本等信息)

Controller manager：

Controller manager作为集群内部的管理控制中心，包括8个controller，同时也是Kubernetes 自动化功能的核心。值得注意的是，其中Service Account Controller、Token Controller是安全相关的两个控制器。

- Replication Controller（简称RC，副本控制器，是用来声明应用副本的个数）

- Node controller（Node Controller通过API Server实时获取Node的相关信息，实现管理和监控集群中的各个Node节点的相关控制功能）

- ResourceQuota Controller（资源配额管理确保指定的资源对象在任何时候都不会超量占用系统物理资源，避免由于某些业务进程的设计或实现的缺陷导致整个系统运行紊乱）

- Namespace Controller（用户通过API Server可以创建新的Namespace并保存在etcd中，Namespace Controller定时通过API Server读取这些Namespace信息）

- Service Controller（k8集群与外部的云平台之间的一个接口控制器。监听Service变化）

- Service account controller（访问控制）

- Token controller（访问控制）

- Endpoints Controller（负责生成和维护所有Endpoints对象的控制器，监听Service和对应的Pod副本的变化）

Scheduler：

作为一个调度室，Scheduler 的作用是，将待调度的 Pod 按照算法和策略绑定到 Node 上，同时将信息保存在 etcd 中。此时 Node 上的 kubelet 通过 APIServer 监听到 Scheduler 产生的 Pod 绑定事件，然后通过 Pod 的描述装载镜像文件，并且启动容器。

Node

Node 作为名副其实的“打工人”，是K8s集群的工作节点，跑着应用，由以下几个部分构成：

- Kubelet服务：负责node与master之间的通信。

- Kube-proxy服务：本质上起到反向代理和负载均衡的作用，方便找到Pod或者容器。集群内部通过kube-proxy服务来进行通信的。

- Docker Engine：它主要是负责节点上的容器的创建和管理。

- Pod：K8s管理的最小单位，同时，每个Pod上可以包含多个容器。Pod中的容器会被Master调度到一个Node上运行。Pod上还有cAdvisor，kublet就是通过Cadvisor来监控容器和节点资源的。

总结一下上面的介绍：Kubernetes 是用来管理容器集群的，Master作为管理者，包括 APIServer，Scheduler，Controller Manager。Node作为副本部署的载体，包含多个Pod，每个Pod又包含多个容器（container）。用户通过kubectl给Master中的APIServer 下部署命令。命令主体则是以“.yaml”结尾的配置文件，包含副本的类型、副本个数、名称、端口、模版等信息。APIServer接受到请求以后，会分别进行以下操作：权限验证（包括特殊控制），取出需要创建的资源，保存副本信息到etcd。APIServer和Controller Manager，Scheduler 以及kubelet之间通过List-Watch方式通信（事件发送与监听）。Controller Manager通过etcd获取需要创建资源的副本数，交由Scheduler进行策略分析。最后kubelet负责最终的Pod创建和容器加载。部署好容器以后，通过Service进行访问，通过cAdvisor监控资源。

Kubernetes常见安全风险

读到这里，想必Kubernetes的神秘面纱已被慢慢揭开。现在，让我们转换话题，聚焦于Kubernetes面临的安全挑战。尤其值得关注的是与容器组件相关的未授权访问问题。在当前“挖矿”横行的背景下，这些服务若遭恶意利用，攻击者很可能迅速夺取对容器、节点乃至整个集群的控制权，是广大公网蠕虫的必争之地。

APIServer

APIServer 是所有功能的主入口，则控制 APIServer 基本上等同控制集群的所有功能。如果配置不合理:`kube-apiserver --insecure-bind-address=0.0.0.0 --insecure-port=8080`，访问ip+port即可得到类似如下信息：

接下来，我们可以使用kubectl（下发用户指令：`kubectl -s "ip:port" get pods`），来获取集群的权限，kubectl 的官方文档可以指导我们通过apiserver更好地进行下一步渗透（https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands）。

Kubelet

Kubelet主要是负责node与master之间的通信。每个Node节点都会有一个kubelet服务，它监听了10250、10248、10255等端口。10250端口是kubelet和apiserver通信的主要端口，用来接收应该处理的任务。在最新版本的Kubernetes中，该端口是有鉴权的，但是，如果为了调试方便而关闭鉴权或者使用旧版本的不安全配置则会导致未授权访问。

我们可以使用`curl ip:port:pods`，来获取集群的详细信息。

显示上面的结果即可证明漏洞存在，我们接着可以使用`curl -k https://Kubernetes-node-ip:10250/run/// -d "cmd=id"`的方式在任意容器里执行命令。

Dashboard

Dashboard 是 Kubernetes 官方推出的图形化界面，当用户开启了 enable-skip-login 时，可以在登录界面点击 Skip 跳过登录进入 dashboard。此时可以通过dashboard来控制整个集群。

但是，通过 skip 进入 dashboard 默认是没有特殊权限的（基于K8s的RBAC机制进行身份认证和权限认证），没法达到控制集群任意功能的程度。重点来了：若产品侧配置错误或为了方便将 Kubernetes dashboard 绑定了 cluster-admin等角色，攻击者可直接在界面上创建特权 pod 进行容器逃逸。

Etcd

Etcd一般用来存储分布式系统或机器集群的数据，它默认监听2379端口。kubernetes默认使用了etcd v3来存储数据，如果控制了etcd服务，也就控制了整个集群。

在 Kubernetes 中用户可以通过配置 /etc/Kubernetes/manifests/etcd.yaml 更改 etcd pod 相关的配置，若管理员通过修改配置将 etcd 监听的 host 修改为 0.0.0.0，则通过 ectd 可以获取 Kubernetes 的认证鉴权 token，从而获取整个集群的控制权。

访问`https://ip:2379/v2/keys`，如下图，即可证明漏洞存在。

可以通过如下指令获取top-levelkeys数据：

`/etcdctl--endpoints=https://etcd_ip:2379/ get / --prefix --keys-only | grep secrets`

通过获取的token访问API-Server，可进一步创建恶意Pod，获取集群管理员的权限。

`kubectl --insecure-skip-tls-verify -s https://*.*.*.*:6443/ --token=“[.token.]” -n kube-system get pods`

Docker Remote Api

Docker Engine API 是 Docker 提供的基于 HTTP 协议的用于 Docker 客户端与 Docker 守护进程交互的 API。Docker daemon 默认监听 2375 端口且未鉴权，攻击者可利用对外暴露的docker remote api，执行docker命令。

检测目标是否存在docker api未授权访问漏洞的方式也很简单，访问 `http://[host]:[port]/info`中是否含有 ContainersRunning、DockerRootDir 等关键字。`docker -H tcp:// [host]:2375 images`命令也可查看靶机docker下容器镜像，从而进一步利用。