当前位置：首页 > news >正文

Kubernetes安全

news 来源：原创 2025/6/24 9:13:03

Kubernetes 又称 k8s，是 Google 在 2014 年开源的一个用来管理容器的平台，以下是 k8s 架构图

Kubernetes 核心组件简介

k8s 主要由以下核心组件组成：

1. etcd（配置中心 & 状态存储）

是一个高可用的 分布式键值数据库，用于持久化存储整个集群的所有状态数据；
例如集群中所有节点、Pod、Service、ConfigMap 等资源的定义与状态都会记录在 etcd 中；
所有组件都通过 API Server 间接与 etcd 交互。

2. API Server（集群的“中枢神经”）

是 Kubernetes 的唯一入口，提供 RESTful 风格的 API 接口；
负责：

- 用户、组件与集群的数据交互；
- 身份认证（Authentication）；
- 权限控制（Authorization）；
- 数据校验与持久化；
- API 注册与发现；

所有对 Kubernetes 的操作（kubectl、controller、scheduler 等）都必须经过 API Server。

3. Controller Manager（控制器管理器）

是一组控制器（Controller）的集合，负责持续地监控集群状态并进行自动化调节；
常见控制器有：

- Node Controller：节点健康检查
- Replication Controller：副本数量维护
- Endpoints Controller：Service 与 Pod 映射
- Job Controller：任务生命周期管理

实现集群的自愈能力、自动扩缩容、滚动更新等功能。

4. Scheduler（调度器）

负责根据调度策略（资源需求、亲和性、污点容忍等）将 Pod 调度到最合适的节点上；
工作流程：

- 监听 API Server 中未调度的 Pod；
- 评估所有可用节点；
- 将调度结果写回 API Server；

是实现 多租户资源优化调度策略 的核心组件。

5. Kubelet（节点守护进程）

是运行在每个节点上的代理，负责：

- 接收 API Server 下发的 Pod 配置；
- 监控 Pod 状态并定期上报；
- 管理容器的生命周期；
- 管理 Volume（CVI）和网络（CNI）；

通过调用容器运行时（CRI）真正执行容器操作。

6. Container Runtime（容器运行时）

是负责镜像拉取、容器创建、启动、停止等的底层组件；
常见运行时：

- Docker（已弃用）
- containerd（推荐）
- CRI-O

通过 CRI（Container Runtime Interface）与 Kubelet 通信，是运行 Pod 的基础。

7. Kube-proxy（网络代理）

运行在每个节点上，负责处理 Service 的访问流量；
主要作用：

- 实现 Kubernetes Service 的服务发现；
- 通过 iptables 或 IPVS 实现负载均衡；

保证集群内部 Pod 之间和对外的通信顺畅稳定。

K8s所面临的风险

K8s集群中常见的风险主要有下面5类：

容器基础设施存在的风险
组件接口存在的风险
集群网络存在的风险
访问控制机制存在的风险
K8s自身漏洞带来的风险

其中第一项和前文docker安全基本一致，直接跳过

组件接口存在的风险

API Server 未授权访问

API Server 是集群的唯一资源操作入口；
默认监听端口为 6443（HTTPS，带认证授权）和 8080（HTTP，默认未开启）；
若管理员错误开启了 8080 并暴露到公网，攻击者无需认证即可直接操作资源，控制整个集群。

Kubelet 未授权访问

Kubelet 是运行在每个节点上的代理，默认监听 10250（HTTPS）和 10248；
若 Kubelet 未配置认证，攻击者可远程访问节点容器、执行命令或窃取数据，造成节点失控；
实战中常见攻击如执行 /exec/ 接口进入容器或获取运行日志。

Dashboard 风险

Dashboard 是 Kubernetes 提供的可视化 Web 控制台；
默认监听本地端口 8001，安全版本要求登录认证；
若管理员开启了“跳过登录”或通过反向代理暴露至公网，攻击者可能无需认证即可控制集群资源。

etcd 泄露风险

etcd 是 Kubernetes 的状态数据库，存储所有资源数据（如 Secrets、配置、服务状态等）；
默认监听端口为 2379（客户端）和 2380（节点间通信）；
如果未启用证书认证，或证书被泄露、匿名访问被开启，则攻击者可直接读取敏感信息，甚至通过写入配置控制集群行为。

集群网络存在的风险

Kubernetes 中的网络默认以「扁平化设计」为主，所有 Pod 默认彼此可通信，缺乏细粒度隔离：

Pod 与 Pod 之间网络默认全通；
Pod 中容器默认具有 CAP_NET_RAW 权限，允许使用原始套接字进行 ARP 欺骗、网络扫描等操作；
攻击者在突破某一 Pod 后，容易通过内网横向访问其他敏感 Pod 或组件，进一步扩大攻击面；
若未配置 NetworkPolicy 或未启用 CNI 插件的隔离策略，风险极高。

访问控制机制存在的风险

Kubernetes 的安全访问控制由三部分组成：

认证（Authentication）：确认用户或组件的身份；
授权（Authorization）：决定是否允许其进行某项操作；
准入控制（Admission Control）：决定请求是否能进入 API Server 的处理流程。

常见风险：

集群开启了匿名访问或默认绑定高权限角色（如将 system:anonymous 绑定至 cluster-admin）；
RBAC 权限配置过于宽泛（如使用 * 表示资源与动作）；
准入控制插件未启用安全策略（如未启用 PodSecurity、ImagePolicy 等）；
攻击者一旦获得访问令牌（Token）、kubeconfig 文件或证书，可能在认证绕过的同时获取极高权限。

无法根治的软件漏洞

Kubernetes 自身也被爆出许多安全漏洞，这类自然也属于 Kubernetes 所面临的的风险

以上纯粹是理论知识，现在针对k8s或是docker的渗透已经完全不和之前一样了，我看一些比较老的书上基本都会说“云渗透和传统渗透的区别不大”。这句话在云刚刚开始起步的时候或许还应验，但是自从2017年后，大大小小各种产品的孵化，加上各种公有云，私有云，混合云，虚拟化集群，各种云原生产品进入企业落地，各个大大小小的企业都喊着“上云”的口号，导致现在云渗透已经没有那么容易那么公式化了，以往渗透是从外网突破-> 提权 -> 权限维持 -> 信息收集 -> 横向移动 -> 循环收集信息获得重要目标系统。随着业务上云以及虚拟化技术的引入改变了这种格局，也打开了新的入侵路径

通过虚拟机攻击云管理平台，利用管理平台控制所有机器
通过容器进行逃逸，从而控制宿主机以及横向渗透到K8s Master节点控制其上所有容器
购买弹性虚拟主机-> KVM-QEMU/执行逃逸 -> 获取宿主机 -> 进入物理网络 -> 横向移动控制云平台

k8s渗透思路

这张图就是k8s大概的攻击面

在学习对k8s的渗透之前，我们要先理解k8s的架构构成

识别容器

首先判断是否为Docker再判断是否为K8s

/run/secrets/kubernetes.io/serviceaccount文件是为Pod中的进程和外部用户提供身份信息

df -h
Filesystem               Size  Used Avail Use% Mounted on
overlay                   50G  3.6G   47G   8% /
tmpfs                     64M     0   64M   0% /dev
tmpfs                    1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/mapper/centos-root   50G  3.6G   47G   8% /etc/hosts
shm                       64M     0   64M   0% /dev/shm
tmpfs            1.9G   12K  1.9G   1% /run/secrets/kubernetes.io/serviceaccount
tmpfs                    1.9G     0  1.9G   0% /proc/acpi
tmpfs                    1.9G     0  1.9G   0% /proc/scsi
tmpfs                    1.9G     0  1.9G   0% /sys/firmware

ls -l /run/secrets/kubernetes.io/serviceaccount/
total 0
lrwxrwxrwx 1 root root 13 Sep 17 01:17 ca.crt -> ..data/ca.crt
lrwxrwxrwx 1 root root 16 Sep 17 01:17 namespace -> ..data/namespace
lrwxrwxrwx 1 root root 12 Sep 17 01:17 token -> ..data/token

主要包含了三个内容

namespace指定了pod所在的namespace
CA用于验证apiserver的证书
token用作身份验证

env环境变量

root@privileged-container:~# env
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_SERVICE_PORT=443
HOSTNAME=privileged-container
DVWA_WEB_SERVICE_PORT=8080
DVWA_WEB_SERVICE_HOST=10.97.153.211
DVWA_WEB_SERVICE_PORT_8080=8080

渗透路线

简单来说渗透路线是这样的：

docker user shell
docker root shell
docker逃逸
内网横向

接下来就是对漏洞的利用，具体利用方法可以看https://lzcloudsecurity.gitbook.io/yun-an-quan-gong-fang-ru-men/di-liu-zhang-yun-yuan-sheng-gong-fang/kubernetes-chang-jian-gong-ji-fang-shi/kubernetes-att-and-ck这篇文章，我就不一一列出了（或者等过两天我上夜班无聊的时候再罗列一下）