红队视角出发的k8s敏感信息收集——Kubernetes API 扩展与未授权访问

针对 Kubernetes API 扩展与未授权访问 的详细攻击视角分析，聚焦 Custom Resource Definitions (CRD) 和 Aggregated API Servers 的潜在攻击面及利用方法：

​

攻击链示例

1. 攻击者通过 ServiceAccount Token 访问集群 → 
2. 枚举 CRD 发现数据库配置资源 → 
3. 提取明文数据库密码 → 
4. 通过未授权的 metrics-server API 定位高负载节点 → 
5. 横向渗透至数据库 Pod。

Custom Resource Definitions (CRD) 攻击场景

目标：通过查询或滥用 CRD，发现自定义资源中的敏感数据（如凭据）、漏洞的自定义控制器，或利用宽松的 RBAC 权限进行提权。

枚举集群中的 CRD

列出所有 CRD

为了枚举Kubernetes集群中的自定义资源定义（Custom Resource Definitions, CRDs），可以使用kubectl get crd命令。这将帮助你了解当前集群中定义了哪些CRD，以及它们的一些基本信息。

执行以下命令来列出集群中所有的CRD，并以宽格式输出（-o wide），以便获取更多细节：

kubectl get crd -o wide

运行上述命令后，你可能会看到类似如下的输出：

NAME                        CREATED AT             AGE
databases.example.com       2024-01-01T12:00:00Z   14m
workflows.argoproj.io       2024-01-02T15:30:00Z   13m

在这个示例输出中：

• NAME 列出了每个CRD的名称。
• CREATED AT 显示了每个CRD创建的时间戳。
• AGE 表明了从创建到现在的时间长度。

如果你想查看某个特定CRD的更详细信息，包括其规格和状态，可以使用kubectl describe命令。例如，要获取关于databases.example.com CRD的详细信息，你可以运行：

kubectl describe crd databases.example.com

此命令会提供该CRD的完整定义，包括它的规格、状态、已建立的资源版本等详细信息，这对于理解CRD的功能及其在集群中的使用情况非常有用。

分析高风险 CRD

敏感数据存储

分析Kubernetes集群中的自定义资源定义（CRD）以识别潜在的安全风险是确保集群安全的重要步骤。以下是两个主要的风险点及如何进行相应的分析：

如果CRD名称包含诸如secret、credential、config等关键词，这可能意味着该CRD用于存储或处理敏感信息。虽然名称本身并不能完全确定其是否真的存储了敏感数据，但它确实是一个重要的提示信号。

你可以通过以下命令过滤出名称中包含特定关键词的CRD：

kubectl get crd -o json | jq '.items[] | select(.metadata.name | contains("secret") or contains("credential") or contains("config")) | .metadata.name'

一旦找到了可能涉及敏感数据的CRD，可以进一步查看它们的详细定义和用途：

kubectl describe crd <crd-name>

通过检查CRD的规范部分（.spec），你可以了解这些资源是如何被使用的，以及它们的数据模型是否确实包含敏感信息。

自定义控制器漏洞

自定义控制器通常与CRD紧密相关，负责监听并处理这些资源的变化。如果控制器镜像存在已知的安全漏洞（CVE），则可能导致严重的安全隐患。

首先，找到与CRD相关的控制器部署。这通常涉及到查找相关的Deployment、StatefulSet或其他工作负载资源。你可以从CRD的描述信息或者直接在集群配置文件中寻找线索。

例如，如果你知道某个CRD是由特定命名空间下的Deployment管理的，可以查看该Deployment的详细信息：

kubectl get deployment -n <namespace> -o yaml | grep image:

这条命令会列出指定命名空间下所有Deployment所使用的容器镜像。

对于每个镜像，你可以使用多种工具和服务来检查是否存在已知