Kubernetes Goat 场景五用 docker-bench-security DaemonSet 在 Kubernetes 节点上执行 Docker CIS 基准审计【免费下载链接】kubernetes-goatKubernetes Goat is a Vulnerable by Design cluster environment to learn and practice Kubernetes security using an interactive hands-on playground 项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-goat本文基于 Kubernetes Goat 仓库中 场景五文档 展开讲解如何把一个容器安全审计工具docker/docker-bench-security以 DaemonSet 形式部署到每个 Kubernetes 节点进入 Pod 执行 Docker CIS 基准检查并读懂其输出的安全发现。读完后你将掌握如何用kubectl部署并操作 DaemonSet 类审计负载、该负载为什么必须使用hostPID/hostNetwork/特权模式等“危险”配置以及如何将审计结果转化为容器安全加固与利用分析的输入。场景背景与学习目标Kubernetes Goat 是一个“故意存在漏洞”Vulnerable by Design的 Kubernetes 集群学习环境其 README 明确提示请勿在生产环境或任何未授权的系统上运行或复现这些攻击手法仅用于教育目的。在仓库列出的 22 个实战场景中第 5 个场景即“Docker CIS benchmarks analysis”Docker CIS 基准分析。该场景的定位继承自场景文档的 Overview是在容器化与云原生生态中执行容器安全审计与评估。你将学习如何对 Docker 容器运行流行的 CIS 基准审计如何操作 Kubernetes 中的 DaemonSet、Pod 及其他集群资源如何获得整个容器安全态势Container security posture的可见性并理解其中的风险。场景故事线是在 Kubernetes 节点之上执行 Docker CIS 基准分析以识别潜在的安全漏洞。完成场景后你可以基于审计输出的漏洞点继续做进一步利用exploitation或修复fixing——这正是审计与合规背景人员转型容器安全时需要的基础能力。部署 Docker CIS 审计 DaemonSet场景文档给出的入口命令只有两条部署与进入容器。# 部署 docker-bench-security DaemonSet kubectl apply -f scenarios/docker-bench-security/deployment.yaml # 进入 Pod 执行审计注意替换为实际的 Pod 名称 kubectl exec -it docker-bench-security-xxxxx -- sh真正的技术含量集中在 scenarios/docker-bench-security/deployment.yaml 这份清单里。它并非一个普通的应用负载而是把一个需要“看到宿主机”的审计工具打包成了集群级 DaemonSet下面逐段解析。文件头部注释等价的 docker run 命令清单开头的注释块给出了一段等价的docker run命令是理解整体设计意图最快的入口docker run -it --net host --pid host --userns host --cap-add audit_control \ -e DOCKER_CONTENT_TRUST$DOCKER_CONTENT_TRUST \ -v /etc:/etc:ro \ -v /lib/systemd/system:/lib/systemd/system:ro \ -v /usr/bin/containerd:/usr/bin/containerd:ro \ -v /usr/bin/runc:/usr/bin/runc:ro \ -v /usr/lib/systemd:/usr/lib/systemd:ro \ -v /var/lib:/var/lib:ro \ -v /var/run/docker.sock:/var/run/docker.sock:ro \ --label docker_bench_security \ docker/docker-bench-security从中可以提取出该审计工具的“最低需求”host 网络/PID/用户命名空间、AUDIT_CONTROL能力、以及对/etc、/var/lib、systemd 目录、containerd/runc二进制与 Docker socket 的只读挂载。Kubernetes 清单正是按这份需求逐项映射出来的。Pod 级别共享宿主机三大命名空间清单中 Pod 模板设置了见 deployment.yamlspec: hostPID: true hostIPC: true hostNetwork: true securityContext: runAsUser: 0hostNetwork: true审计脚本需要检查节点上的网络配置与端口暴露必须使用宿主机网络栈hostPID: trueCIS Docker 检查项中大量涉及进程、容器运行时状态需要看到宿主 PID 命名空间内的所有进程hostIPC: true检查共享内存段等 IPC 资源时需要runAsUser: 0以 root 身份运行配合后文挂载只读的系统目录。这四行组合起来就是典型的“节点级审计/运维负载”形态也是它天然违反容器最小化原则的原因——在本项目中这是刻意设计用于演示“审计工具本身需要多大权限”这一安全议题。Init 容器验证容器运行时 socket 是否存在清单声明了一个名为verify-runtime-socket的 init 容器deployment.yaml#L32-L56initContainers: - name: verify-runtime-socket image: busybox:latest command: - sh - -c - | echo Checking for container runtime socket... if [ -S /host-root/var/run/docker.sock ]; then echo ✓ Docker socket found at /var/run/docker.sock elif [ -S /host-root/run/docker.sock ]; then echo ✓ Docker socket found at /run/docker.sock elif [ -S /host-root/run/containerd/containerd.sock ]; then echo ✓ Containerd socket found at /run/containerd/containerd.sock else echo ⚠ No container runtime socket found! echo This may cause docker-bench-security to fail fi volumeMounts: - name: host-root mountPath: /host-root readOnly: true securityContext: privileged: true它通过把宿主机根目录/以hostPath只读挂载到/host-root依次探测三个候选 socket 路径/var/run/docker.sockDocker 最常见路径/run/docker.sock部分发行版下/var/run是/run的软链作为备用路径/run/containerd/containerd.sock节点若直接使用 containerd 作为运行时。从源码结构看这是一个“环境自检”设计因为不同集群Docker、containerd、k3s 等的 socket 位置不同init 容器先打印诊断信息帮助使用者在主容器启动前就知道审计能否正常工作。需要注意 init 容器自身使用了privileged: true。主容器hacker-container 镜像与审计所需挂载主容器配置见 deployment.yaml#L57-L103containers: - name: docker-bench image: madhuakula/hacker-container imagePullPolicy: Always command: [/bin/sh, -c, sleep infinity] resources: requests: cpu: 20m memory: 50Mi limits: cpu: 50m memory: 80Mi securityContext: privileged: true capabilities: add: [AUDIT_CONTROL]几个值得注意的实现细节镜像与入口使用madhuakula/hacker-containerKubernetes Goat 系列场景共用的攻击者容器仓库文档中多个场景也引用该镜像可参考 场景 14 文档 中对 hacker container 的介绍。容器内已预装docker-bench-security与场景文档提示“docker-bench-security is already installed inside the container”一致。sleep infinity前台命令容器不自动执行审计而是保持一个交互式 shell 会话供使用者kubectl exec进入后手动运行检查。这是“交互式靶场”的常见做法——审计动作由学习者主动触发便于观察每一步输出。资源限额requests 为 20m CPU / 50Mi 内存limits 为 50m / 80Mi属于极低占用保证 DaemonSet 在所有节点上常驻也不会挤占资源。privileged: trueAUDIT_CONTROL特权模式使容器可以访问宿主机全部设备并绕过大部分隔离额外添加的AUDIT_CONTROL能力与注释中docker run的--cap-add audit_control一一对应CIS Docker 基准中对auditd配置的检查项会用到该能力。只读挂载的宿主机目录与 socket主容器的volumeMounts把以下宿主机路径挂入容器全部readOnly: true容器内路径宿主机路径用途对应 CIS 检查项类别/var/lib/var/lib容器镜像/卷存储位置检查镜像来源与存储配置/usr/lib/systemd/usr/lib/systemdsystemd 服务配置检查/etc/etc检查daemon.json、auditd、sshd等系统配置/lib/systemd/system/lib/systemd/system服务单元文件检查/usr/bin/containerd/usr/bin/containerd运行时二进制存在性/配置检查/usr/bin/runc/usr/bin/runc同上/var/run/docker.sock/var/run/docker.sock主 Docker socket 路径/run/docker.sock/run/docker.sock备用 Docker socket 路径/run/containerd/containerd.sock/run/containerd/containerd.sockcontainerd 运行时 socket对应volumes部分deployment.yaml#L104-L138中三个 socket 类 hostPath 均声明了type: DirectoryOrCreate。从源码结构看这是一个兼容不同节点的容错设计若节点上该路径不存在例如没有安装 DockerKubelet 会自动创建该路径避免 Pod 因hostPath校验失败而无法启动。进入 Pod 并运行 CIS 基准审计部署成功后按场景文档的 Solution 流程操作# 1. 确认 DaemonSet 的 Pod 在每个节点都已 Running kubectl get pods # 2. 选择任意一个 docker-bench-security-xxxxx Pod 并进入 kubectl exec -it docker-bench-security-xxxxx -- sh # 3. 进入容器内已预装的审计目录 cd docker-bench-security # 4. 启动 Docker CIS 基准检查脚本 sh docker-bench-security.shsh docker-bench-security.sh会依次执行工具内置的检查项PASS/FAIL/INFO/MANUAL 四态输出覆盖的典型类别包括Docker 守护进程配置daemon.json中的 TLS、调试模式、--insecure-registry等、Docker socket 暴露面、用户与命名空间隔离、容器能力与 AppArmor/seccomp/Rootless 配置、审计日志auditd启用状态、系统内核参数等。脚本结束后会汇总各检查项结果输出系统上全部安全问题和配置缺陷。场景文档在 Hints Spoilers 中给出的关键提示是不确定如何运行审计时直接查看容器内的docker-bench-security目录——工具自包含于镜像无需额外安装。从审计结果走向利用或加固场景文档明确说明了两条后续路径“based on the vulnerabilities you see from the Docker CIS benchmarks, you can proceed with further exploitation”——即根据审计发现继续做利用或者修复这些 misconfiguration 与 vulnerabilities。这正是场景在“审计与合规”视角下的价值对防守方审计输出的 FAIL 项就是加固清单例如 socket 未设访问控制、以 root 运行、共享宿主命名空间等每一项都对应可执行的修复动作对红队/学习者审计结果揭示了节点上“哪些门是开着的”。例如 Docker socket 挂载到容器等价于获得宿主机容器编排权限host PID/网络命名空间共享则扩大了侦察面——这些发现可直接衔接到仓库中其他场景如容器逃逸、DIND 利用的练习。一个“以攻促防”的佐证Checkov 对这份清单本身也有大量告警这份审计负载的清单本身就是一个极好的反面教材。仓库内置的 Checkov 安全报告 中/scenarios/docker-bench-security/deployment.yaml被密集命中了十几条规则摘录几条规则描述CKV_K8S_16Container should not be privilegedCKV_K8S_19Containers should not share the host network namespaceCKV_K8S_17Containers should not share the host process ID namespaceCKV_K8S_18Containers should not share the host IPC namespaceCKV_K8S_27Do not expose the docker daemon socket to containersCKV_K8S_23Minimize the admission of root containersCKV_K8S_31Ensure that the seccomp profile is set to docker/default or runtime/default这与上文对deployment.yaml的逐行分析完全吻合privileged: true、三个 host 命名空间、Docker socket 挂载、runAsUser: 0都被静态扫描器独立确认。可以推断Kubernetes Goat 故意保留这些“不安全”写法是为了让学习者同时体验两件事审计工具为什么需要这些权限以及为什么在生产环境中绝不应以这种方式部署任何负载。环境与操作前提需要可kubectl管理集群的权限Kubernetes Goat 的 setup 脚本 在初始化时会通过 scenarios/insecure-rbac/setup.yaml 创建superadminServiceAccount 并绑定cluster-admin为各场景提供集群级操作能力——因此场景内的kubectl apply/exec操作可顺利完成。该清单不属于 setup 脚本自动部署的部分脚本中未包含docker-bench-security需要按场景文档手动kubectl apply部署用完后可自行删除。节点需存在 Docker 或 containerd 运行时之一init 容器的探测输出可用于确认 socket 是否可用。若节点两者皆无审计脚本的大部分检查将失去目标init 容器会打印 “No container runtime socket found” 警告。相关仓库路径索引路径说明guide/docs/scenarios/scenario-5/scenario-5.md场景五完整文档目标、步骤、提示scenarios/docker-bench-security/deployment.yaml审计 DaemonSet 清单本文核心分析对象guide/docs/security-reports/checkov.md对仓库各清单的 Checkov 扫描结果含该清单的告警项infrastructure/goat-home/home/content/scenario-5.md靶场首页中场景五的入口页含部署命令README.md项目总览、22 个场景列表与运行前提【免费下载链接】kubernetes-goatKubernetes Goat is a Vulnerable by Design cluster environment to learn and practice Kubernetes security using an interactive hands-on playground 项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-goat创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes Goat 场景五：用 docker-bench-security DaemonSet 在 Kubernetes 节点上执行 Docker CIS 基准审计
Kubernetes Goat 场景五用 docker-bench-security DaemonSet 在 Kubernetes 节点上执行 Docker CIS 基准审计【免费下载链接】kubernetes-goatKubernetes Goat is a Vulnerable by Design cluster environment to learn and practice Kubernetes security using an interactive hands-on playground 项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-goat本文基于 Kubernetes Goat 仓库中 场景五文档 展开讲解如何把一个容器安全审计工具docker/docker-bench-security以 DaemonSet 形式部署到每个 Kubernetes 节点进入 Pod 执行 Docker CIS 基准检查并读懂其输出的安全发现。读完后你将掌握如何用kubectl部署并操作 DaemonSet 类审计负载、该负载为什么必须使用hostPID/hostNetwork/特权模式等“危险”配置以及如何将审计结果转化为容器安全加固与利用分析的输入。场景背景与学习目标Kubernetes Goat 是一个“故意存在漏洞”Vulnerable by Design的 Kubernetes 集群学习环境其 README 明确提示请勿在生产环境或任何未授权的系统上运行或复现这些攻击手法仅用于教育目的。在仓库列出的 22 个实战场景中第 5 个场景即“Docker CIS benchmarks analysis”Docker CIS 基准分析。该场景的定位继承自场景文档的 Overview是在容器化与云原生生态中执行容器安全审计与评估。你将学习如何对 Docker 容器运行流行的 CIS 基准审计如何操作 Kubernetes 中的 DaemonSet、Pod 及其他集群资源如何获得整个容器安全态势Container security posture的可见性并理解其中的风险。场景故事线是在 Kubernetes 节点之上执行 Docker CIS 基准分析以识别潜在的安全漏洞。完成场景后你可以基于审计输出的漏洞点继续做进一步利用exploitation或修复fixing——这正是审计与合规背景人员转型容器安全时需要的基础能力。部署 Docker CIS 审计 DaemonSet场景文档给出的入口命令只有两条部署与进入容器。# 部署 docker-bench-security DaemonSet kubectl apply -f scenarios/docker-bench-security/deployment.yaml # 进入 Pod 执行审计注意替换为实际的 Pod 名称 kubectl exec -it docker-bench-security-xxxxx -- sh真正的技术含量集中在 scenarios/docker-bench-security/deployment.yaml 这份清单里。它并非一个普通的应用负载而是把一个需要“看到宿主机”的审计工具打包成了集群级 DaemonSet下面逐段解析。文件头部注释等价的 docker run 命令清单开头的注释块给出了一段等价的docker run命令是理解整体设计意图最快的入口docker run -it --net host --pid host --userns host --cap-add audit_control \ -e DOCKER_CONTENT_TRUST$DOCKER_CONTENT_TRUST \ -v /etc:/etc:ro \ -v /lib/systemd/system:/lib/systemd/system:ro \ -v /usr/bin/containerd:/usr/bin/containerd:ro \ -v /usr/bin/runc:/usr/bin/runc:ro \ -v /usr/lib/systemd:/usr/lib/systemd:ro \ -v /var/lib:/var/lib:ro \ -v /var/run/docker.sock:/var/run/docker.sock:ro \ --label docker_bench_security \ docker/docker-bench-security从中可以提取出该审计工具的“最低需求”host 网络/PID/用户命名空间、AUDIT_CONTROL能力、以及对/etc、/var/lib、systemd 目录、containerd/runc二进制与 Docker socket 的只读挂载。Kubernetes 清单正是按这份需求逐项映射出来的。Pod 级别共享宿主机三大命名空间清单中 Pod 模板设置了见 deployment.yamlspec: hostPID: true hostIPC: true hostNetwork: true securityContext: runAsUser: 0hostNetwork: true审计脚本需要检查节点上的网络配置与端口暴露必须使用宿主机网络栈hostPID: trueCIS Docker 检查项中大量涉及进程、容器运行时状态需要看到宿主 PID 命名空间内的所有进程hostIPC: true检查共享内存段等 IPC 资源时需要runAsUser: 0以 root 身份运行配合后文挂载只读的系统目录。这四行组合起来就是典型的“节点级审计/运维负载”形态也是它天然违反容器最小化原则的原因——在本项目中这是刻意设计用于演示“审计工具本身需要多大权限”这一安全议题。Init 容器验证容器运行时 socket 是否存在清单声明了一个名为verify-runtime-socket的 init 容器deployment.yaml#L32-L56initContainers: - name: verify-runtime-socket image: busybox:latest command: - sh - -c - | echo Checking for container runtime socket... if [ -S /host-root/var/run/docker.sock ]; then echo ✓ Docker socket found at /var/run/docker.sock elif [ -S /host-root/run/docker.sock ]; then echo ✓ Docker socket found at /run/docker.sock elif [ -S /host-root/run/containerd/containerd.sock ]; then echo ✓ Containerd socket found at /run/containerd/containerd.sock else echo ⚠ No container runtime socket found! echo This may cause docker-bench-security to fail fi volumeMounts: - name: host-root mountPath: /host-root readOnly: true securityContext: privileged: true它通过把宿主机根目录/以hostPath只读挂载到/host-root依次探测三个候选 socket 路径/var/run/docker.sockDocker 最常见路径/run/docker.sock部分发行版下/var/run是/run的软链作为备用路径/run/containerd/containerd.sock节点若直接使用 containerd 作为运行时。从源码结构看这是一个“环境自检”设计因为不同集群Docker、containerd、k3s 等的 socket 位置不同init 容器先打印诊断信息帮助使用者在主容器启动前就知道审计能否正常工作。需要注意 init 容器自身使用了privileged: true。主容器hacker-container 镜像与审计所需挂载主容器配置见 deployment.yaml#L57-L103containers: - name: docker-bench image: madhuakula/hacker-container imagePullPolicy: Always command: [/bin/sh, -c, sleep infinity] resources: requests: cpu: 20m memory: 50Mi limits: cpu: 50m memory: 80Mi securityContext: privileged: true capabilities: add: [AUDIT_CONTROL]几个值得注意的实现细节镜像与入口使用madhuakula/hacker-containerKubernetes Goat 系列场景共用的攻击者容器仓库文档中多个场景也引用该镜像可参考 场景 14 文档 中对 hacker container 的介绍。容器内已预装docker-bench-security与场景文档提示“docker-bench-security is already installed inside the container”一致。sleep infinity前台命令容器不自动执行审计而是保持一个交互式 shell 会话供使用者kubectl exec进入后手动运行检查。这是“交互式靶场”的常见做法——审计动作由学习者主动触发便于观察每一步输出。资源限额requests 为 20m CPU / 50Mi 内存limits 为 50m / 80Mi属于极低占用保证 DaemonSet 在所有节点上常驻也不会挤占资源。privileged: trueAUDIT_CONTROL特权模式使容器可以访问宿主机全部设备并绕过大部分隔离额外添加的AUDIT_CONTROL能力与注释中docker run的--cap-add audit_control一一对应CIS Docker 基准中对auditd配置的检查项会用到该能力。只读挂载的宿主机目录与 socket主容器的volumeMounts把以下宿主机路径挂入容器全部readOnly: true容器内路径宿主机路径用途对应 CIS 检查项类别/var/lib/var/lib容器镜像/卷存储位置检查镜像来源与存储配置/usr/lib/systemd/usr/lib/systemdsystemd 服务配置检查/etc/etc检查daemon.json、auditd、sshd等系统配置/lib/systemd/system/lib/systemd/system服务单元文件检查/usr/bin/containerd/usr/bin/containerd运行时二进制存在性/配置检查/usr/bin/runc/usr/bin/runc同上/var/run/docker.sock/var/run/docker.sock主 Docker socket 路径/run/docker.sock/run/docker.sock备用 Docker socket 路径/run/containerd/containerd.sock/run/containerd/containerd.sockcontainerd 运行时 socket对应volumes部分deployment.yaml#L104-L138中三个 socket 类 hostPath 均声明了type: DirectoryOrCreate。从源码结构看这是一个兼容不同节点的容错设计若节点上该路径不存在例如没有安装 DockerKubelet 会自动创建该路径避免 Pod 因hostPath校验失败而无法启动。进入 Pod 并运行 CIS 基准审计部署成功后按场景文档的 Solution 流程操作# 1. 确认 DaemonSet 的 Pod 在每个节点都已 Running kubectl get pods # 2. 选择任意一个 docker-bench-security-xxxxx Pod 并进入 kubectl exec -it docker-bench-security-xxxxx -- sh # 3. 进入容器内已预装的审计目录 cd docker-bench-security # 4. 启动 Docker CIS 基准检查脚本 sh docker-bench-security.shsh docker-bench-security.sh会依次执行工具内置的检查项PASS/FAIL/INFO/MANUAL 四态输出覆盖的典型类别包括Docker 守护进程配置daemon.json中的 TLS、调试模式、--insecure-registry等、Docker socket 暴露面、用户与命名空间隔离、容器能力与 AppArmor/seccomp/Rootless 配置、审计日志auditd启用状态、系统内核参数等。脚本结束后会汇总各检查项结果输出系统上全部安全问题和配置缺陷。场景文档在 Hints Spoilers 中给出的关键提示是不确定如何运行审计时直接查看容器内的docker-bench-security目录——工具自包含于镜像无需额外安装。从审计结果走向利用或加固场景文档明确说明了两条后续路径“based on the vulnerabilities you see from the Docker CIS benchmarks, you can proceed with further exploitation”——即根据审计发现继续做利用或者修复这些 misconfiguration 与 vulnerabilities。这正是场景在“审计与合规”视角下的价值对防守方审计输出的 FAIL 项就是加固清单例如 socket 未设访问控制、以 root 运行、共享宿主命名空间等每一项都对应可执行的修复动作对红队/学习者审计结果揭示了节点上“哪些门是开着的”。例如 Docker socket 挂载到容器等价于获得宿主机容器编排权限host PID/网络命名空间共享则扩大了侦察面——这些发现可直接衔接到仓库中其他场景如容器逃逸、DIND 利用的练习。一个“以攻促防”的佐证Checkov 对这份清单本身也有大量告警这份审计负载的清单本身就是一个极好的反面教材。仓库内置的 Checkov 安全报告 中/scenarios/docker-bench-security/deployment.yaml被密集命中了十几条规则摘录几条规则描述CKV_K8S_16Container should not be privilegedCKV_K8S_19Containers should not share the host network namespaceCKV_K8S_17Containers should not share the host process ID namespaceCKV_K8S_18Containers should not share the host IPC namespaceCKV_K8S_27Do not expose the docker daemon socket to containersCKV_K8S_23Minimize the admission of root containersCKV_K8S_31Ensure that the seccomp profile is set to docker/default or runtime/default这与上文对deployment.yaml的逐行分析完全吻合privileged: true、三个 host 命名空间、Docker socket 挂载、runAsUser: 0都被静态扫描器独立确认。可以推断Kubernetes Goat 故意保留这些“不安全”写法是为了让学习者同时体验两件事审计工具为什么需要这些权限以及为什么在生产环境中绝不应以这种方式部署任何负载。环境与操作前提需要可kubectl管理集群的权限Kubernetes Goat 的 setup 脚本 在初始化时会通过 scenarios/insecure-rbac/setup.yaml 创建superadminServiceAccount 并绑定cluster-admin为各场景提供集群级操作能力——因此场景内的kubectl apply/exec操作可顺利完成。该清单不属于 setup 脚本自动部署的部分脚本中未包含docker-bench-security需要按场景文档手动kubectl apply部署用完后可自行删除。节点需存在 Docker 或 containerd 运行时之一init 容器的探测输出可用于确认 socket 是否可用。若节点两者皆无审计脚本的大部分检查将失去目标init 容器会打印 “No container runtime socket found” 警告。相关仓库路径索引路径说明guide/docs/scenarios/scenario-5/scenario-5.md场景五完整文档目标、步骤、提示scenarios/docker-bench-security/deployment.yaml审计 DaemonSet 清单本文核心分析对象guide/docs/security-reports/checkov.md对仓库各清单的 Checkov 扫描结果含该清单的告警项infrastructure/goat-home/home/content/scenario-5.md靶场首页中场景五的入口页含部署命令README.md项目总览、22 个场景列表与运行前提【免费下载链接】kubernetes-goatKubernetes Goat is a Vulnerable by Design cluster environment to learn and practice Kubernetes security using an interactive hands-on playground 项目地址: https://gitcode.com/GitHub_Trending/ku/kubernetes-goat创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考