【云安全】云原生-K8S（四）安全问题分析

Kubernetes（K8S）因其强大的容器编排能力成为了云计算和微服务架构的首选，但同时也带来了复杂的安全挑战。本文将概述K8S的主要安全问题，帮助安全工程师理解潜在威胁，并采取相应的防护措施。 

K8S 攻击面概览

下面两张图总结了 K8S 集群架构中可能存在的安全问题，并在第一张K8S 集群基础架构图中直观标出了潜在的攻击点。

下面是K8S组件存在隐患的默认端口：

Kubernetes (K8s) 的安全问题主要来源于不安全的配置，尤其是未授权访问，另外就是配置的泄露。K8s 作为一个复杂的容器编排系统，涉及多个组件和配置文件，如果没有良好的安全控制和严格的配置管理，可能会引发各种安全风险。

一、API Server 未授权访问

API Server 是 Kubernetes 集群的核心管理接口，所有资源请求和操作都通过 kube-apiserver 提供的 API 进行处理。默认情况下，API Server 会监听两个端口：8080 和 6443。如果配置不当，可能会导致未授权访问的安全风险。

8080 端口默认情况下不启用，该端口不需要认证和授权检查。如果意外暴露（v1.20以下版本），攻击者可以直接访问集群资源，导致未授权访问。--insecure-port 和 --insecure-bind-address 参数已经被 废弃，在 Kubernetes v1.20+ 版本中它们已经无法正常使用，尤其是 --insecure-port，只能被设置为 0，否则会导致 API Server 启动失败。

6443 端口默认启用，并且要求认证。如果配置错误，例如将 `system:anonymous` 用户绑定到 `cluster-admin` 用户组，攻击者可能绕过认证，获得集群管理员权限，造成未授权访问。

具体分析文章：【云安全】云原生- K8S API Server 未授权访问-CSDN博客

二、Kubectl Proxy 不安全配置

kubectl proxy 的作用是将 Kubernetes API Server 暴露给本地网络或客户端，允许你通过本地代理与 Kubernetes 集群进行交互。具体来说，kubectl proxy 可以暴露以下内容：

1、Kubernetes API Server

暴露的内容：kubectl proxy 允许你通过代理访问 Kubernetes API Server，进行集群管理和操作。这包括访问集群资源（如 Pods、Services、Deployments、ConfigMaps 等），执行命令（例如 kubectl get、kubectl apply）。

风险：如果没有配置适当的认证和授权，任何可以访问代理端口的用户都可以通过它进行操作，甚至执行恶意行为。即导致了“API Server未授权访问”

漏洞复现：

kubectl proxy --port=8080 --address=0.0.0.0 --accept-hosts='.*' &

#验证，查看进程
ps aux | grep kubectl | grep -v grep

#关闭
kill <PID>

典型的API Server未授权访问页面，具体分析见上文“API Server 未授权访问”

2、Kubernetes Dashboard

暴露的内容：如果你在集群中部署了 Kubernetes Dashboard，kubectl proxy 可以暴露该 Dashboard 的 Web 界面，使你能够通过浏览器访问 Dashboard。默认情况下，Dashboard 可以在 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ 访问。

风险：如果没有启用适当的认证（如 OIDC 或 RBAC），攻击者可能利用代理访问 Dashboard，并进行未授权的操作。具体分析见下文“Dashboard未授权访问”！

3、集群内的其他服务

暴露的内容：kubectl proxy 还可以访问集群中暴露的其他服务和端点。例如，通过代理，你可以访问 Kubernetes 集群中的某些 HTTP 服务，尤其是那些已通过 Kubernetes Service 暴露的服务。

风险：如果某些服务没有进行适当的身份验证或授权控制，攻击者可能利用 kubectl proxy 访问这些服务，并执行恶意操作。

4、API 扩展端点

暴露的内容：Kubernetes 支持 API 扩展，如自定义资源定义（CRDs）。kubectl proxy 允许你访问和管理这些扩展 API 端点。

风险：如果这些自定义资源没有严格的访问控制，攻击者可以通过 kubectl proxy 修改或删除重要资源。

三、etcd 未授权访问

在 Kubernetes (K8s) 中，etcd 是一个关键的分布式键值存储系统，它存储了集群的所有配置信息和状态数据。由于它存储着 K8s 集群的核心数据，因此保护 etcd 是非常重要的。以下是 etcd 未授权访问产生的原因：

1、未加密的数据传输：

默认情况下，etcd 可能会在集群中使用未加密的 HTTP 通信协议。没有加密的传输可能导致中间人攻击（MITM），攻击者可能会截获、篡改或伪造请求，进而导致敏感数据泄露。

2、未加密的数据存储：

如果 etcd 的数据存储未加密，存储在磁盘上的敏感数据（如 API 密钥、身份验证凭证等）可能会被未经授权的用户访问。如果攻击者能够访问存储卷，他们可能会窃取这些数据。

3、缺乏认证和授权：

如果 etcd 没有启用身份验证和授权机制，任何能够访问 etcd 实例的用户或进程都可以读写数据。缺乏访问控制会导致潜在的安全漏洞，攻击者可以篡改配置或获取敏感数据。

4、不安全的集群通信：

如果 etcd 集群之间的通信没有加密或者没有正确配置 TLS，集群成员之间的通信可能会受到攻击。攻击者可以伪造数据或与集群进行恶意交互。

5、未经审计的访问：

如果没有启用审计日志，etcd 可能无法记录所有对数据的访问和修改。缺乏审计日志使得追踪恶意行为变得困难，增加了诊断和响应的复杂性。

6、Etcd 服务的暴露：

如果 etcd 服务被公开在互联网上且没有妥善保护（如防火墙规则、网络隔离、身份验证等），攻击者可以直接访问 etcd，造成安全风险。

具体分析文章：【云安全】云原生- K8S etcd 未授权访问-CSDN博客

四、Kubelet 未授权访问

Kubelet未授权访问通常指的是未经过身份验证的用户或服务能够直接访问Kubelet的API，可能导致集群安全风险。Kubelet负责管理每个节点上的Pod和容器，若未授权访问未被妥善管控，攻击者可以利用此漏洞获取敏感信息或控制容器。

该问题主要是由 /var/lib/kubelet/config.yaml 以下不安全配置引起

10250端口：默认开启端口，但是需要授权

10255端口：只读端口，默认不开放，需要进行配置

具体分析文章：【云安全】云原生- K8S Kubelet 未授权访问-CSDN博客

五、kubeconfig文件泄露

kubeconfig 文件是 Kubernetes 的配置文件，kubectl 使用它来连接和与 Kubernetes 集群交互。它通常位于 ~/.kube/config 路径下，包含多个上下文、集群、用户的配置信息，用于定义 kubectl 如何与不同的集群进行通信。 

kubeconfig 文件如果泄露，可能会导致攻击者获得对 Kubernetes 集群的访问权限。常见的泄露途径包括：将其上传至版本控制系统（如 GitHub）时未忽略该文件，存储在不安全的目录中，或通过不当的权限管理使得文件可被其他用户读取。攻击者可以通过 Webshell、GitHub 等方式获取到此文件，从而通过 API Server 接管整个 Kubernetes 集群，控制所有容器。kubeconfig 文件作为集群的管理凭证，包含关于集群的详细信息，如 API Server 地址、认证凭证等。如果攻击者能够访问到该文件（如办公网员工机器被入侵或文件泄露到 GitHub），他们可以直接通过 API Server 获得集群的控制权限，导致严重的安全风险和隐患。

具体分析文章：【云安全】云原生- K8S kubeconfig 文件泄露-CSDN博客

六、Dashboard未授权访问

面板安装教程：【云安全】云原生-K8S（三） 安装 Dashboard 面板-CSDN博客 

漏洞复现

通过以下命令编辑deployment

kubectl -n kubernetes-dashboard edit deployment kubernetes-dashboard

将以下配置添加到args字段中

- --enable-skip-login

这样就可以在登录界面点击跳过登录进dashboard 

将默认的Kubernetes-dashboard绑定cluster-admin，拥有管理集群管权限 

kubectl create clusterrolebinding dashboard-1 --clusterrole=cluster-admin --serviceaccount=kubernetes-dashboard:kubernetes-dashboard

访问Kubernetes 仪表盘，出现了跳过按钮，点击跳过进入dashboard

创建恶意POD

总结

K8S提供了强大的容器编排能力，但同时也带来了诸多安全风险，尤其是未授权访问风险。至于其他web安全通用问题（如XSS、SQL注入等）和容器特有的安全问题（如镜像漏洞、容器隔离性问题等），虽然对K8s来说也是需要关注的，但从K8s本身的架构和配置角度来说，确实更多的是与配置相关的安全问题。如果你有任何关于K8S安全的疑问或想深入了解具体攻击手法，欢迎在评论区讨论！