【免费下载链接】charts⚠️(OBSOLETE) Curated applications for Kubernetes项目地址https://gitcode.com/gh_mirrors/chart/charts点击查看免费下载本文以当前仓库 stable/kube-hunter/README.md 为骨架完整介绍该 Chart 的安装方式、全部可配置参数并结合 templates/cronjob.yaml、values.yaml 等源码逐层拆解其工作原理与渲染细节。读完本文你将掌握如何通过一条 Helm 命令把 kube-hunter 以 Pod 模式部署为集群内定时的 CronJob 安全扫描任务能够熟练用--set调整扫描频率、并发策略、历史 Job 保留数量与容器镜像并理解从 values 到最终 YAML 清单的完整渲染链路为自定义改造该 Chart 打下基础。一、Chart 定位与仓库状态stable/kube-hunter是当前仓库stable/目录下的一个 Kubernetes Helm Chart用于在集群内部署 kube-hunter 的home与sources字段。其核心设计非常聚焦不部署常驻 Service、Deployment 或 DaemonSet而是创建一个 CronJob按计划定时启动一个 kube-hunter Pod以集群内部视角执行安全弱点扫描。需要特别说明的是该 Chart 当前处于弃用deprecated状态这点有两处明确的仓库证据Chart.yaml 中description为DEPRECATED - A Helm chart for Kube-hunter且显式声明deprecated: trueREADME.md 顶部有独立的DEPRECATION NOTICE段落说明该 Chart 已弃用、不再获得支持。同时整个仓库本身也已进入归档状态README 开头的 Repo Archive Notice 说明 2020 年 11 月 13 日起不再更新。因此本文内容以仓库中当前实际存在的代码为准若要在生产环境使用 kube-hunter建议优先关注其上游项目的最新发布形态若仍需使用本 Chart请先理解下述限制后再评估。从文件结构看该 Chart 非常精简总共只有 5 个文件stable/kube-hunter/ ├── Chart.yaml # Chart 元数据名称、版本、弃用标记 ├── README.md # 官方使用文档本文骨架来源 ├── values.yaml # 默认配置值 └── templates/ ├── NOTES.txt # 安装成功后的提示信息模板 ├── _helpers.tpl # 名称/标签渲染辅助函数 └── cronjob.yaml # 唯一的资源模板CronJob其中 Chart.yaml 记录了版本信息Chart 版本1.0.5appVersion: 312与默认镜像 tag 一致关键词为kubernetes、kube-hunter、security。二、工作原理Pod 模式的定时安全扫描README 的 Chart Details 一节明确说明该 Chart 会创建一个以 Pod 模式运行 kube-hunter 的 CronJob。所谓 Pod 模式指的是 kube-hunter 不再以本机二进制或外部网络探针的形式运行而是作为集群内的一个 Pod 启动从集群内部去探测常见的安全弱点。这一设计在 templates/cronjob.yaml 中有直接的实现证据kind: CronJob spec: schedule: {{ .Values.cronjob.schedule }} jobTemplate: spec: template: spec: restartPolicy: Never containers: - name: {{ .Chart.Name }} image: {{ .Values.image.repository }}:{{ .Values.image.tag }} imagePullPolicy: {{ .Values.image.pullPolicy }} command: [ python, kube-hunter.py ] args: - --pod关键点如下入口命令容器以python kube-hunter.py作为 command并固定携带--pod参数这与上游 kube-hunter 的 Pod 运行模式一致Chart.yaml 的sources也指向了上游的job.yaml一次性执行restartPolicy: NeverJob 内的 Pod 只运行一次扫描完成即退出不会常驻占用资源按计划触发整个 Job 由 CronJob 按cronjob.schedule定时拉起默认每天 UTC 时间 01:00 执行一次见 values.yaml 的注释 At 01:00 every day结果落在 Pod 日志扫描输出直接写入该次 Job 对应 Pod 的标准输出用户通过kubectl logs查看结果而不需要额外的存储或上报组件详见 NOTES.txt 的说明。这种定时 集群内视角的形态适合把安全巡检固化成周期性任务每天固定时刻自动扫一遍集群运维人员只需定期检查 Job 日志即可。三、安装与基础使用README 给出的安装命令非常直接$ helm install stable/kube-hunter这是 Helm v2 时代针对远程stable仓库的典型用法在当前仓库场景下也可以对本地 Chart 目录直接安装例如$ helm install ./stable/kube-hunter如需覆盖默认配置README 明确说明使用--set keyvalue[,keyvalue]语法$ helm install stable/kube-hunter --set cronjob.schedule0 6 * * * --set image.taglatest也可以把全部自定义值写进一个 YAML 文件用--values或-f传入$ helm install stable/kube-hunter -f my-kube-hunter-values.yaml安装完成后Helm 会渲染 NOTES.txt 作为使用提示其中包含三条关键信息调度时间以 UTC 表示A CronJob will run with schedule {{ .Values.cronjob.schedule }}, denoted in UTC.即默认0 1 * * *指的是 UTC 01:00换算到东八区是每天早上 09:00规划扫描时间时务必注意时区历史 Job 保留数量提示会保留 N 个失败 Job 和 N 个成功 Job对应下文配置表中的两个 historyLimit 参数卸载时 Job 不会自动清理The Jobs will not be removed automagically when deleting this Helm chart.需要手动执行清理命令具体见下文第六节。四、完整配置参数说明继承自 README 并扩充README 的核心价值在于其完整参数表。下表完整继承README 内容并在每行补充了 values.yaml 中的实际默认值与影响说明ParameterDescriptionDefaultcustomArgumentsAdditional custom arguments to give to kube-hunter[]image.pullPolicyContainer pull policyIfNotPresentimage.repositoryContainer image to useaquasec/kube-hunterimage.tagContainer image tag to deploy312cronjob.scheduleSchedule for the CronJob0 1 * * *cronjob.annotationsAnnotations to add to the cronjob{}cronjob.concurrencyPolicyAllow|Forbid|Replaceconcurrent jobsForbidcronjob.failedJobsHistoryLimitSpecify the number of failed Jobs to keep1cronjob.successfulJobsHistoryLimitSpecify the number of completed Jobs to keep1pod.annotationsAnnotations to add to the pod{}resourcesResource requests and limits{}priorityClassNamepriorityClassNamenil4.1 参数逐个解读cronjob.schedule默认0 1 * * *CronJob 的 cron 表达式控制扫描任务何时触发。默认每天早上 1 点UTC执行一次任何合法的 cron 表达式均可例如0 */6 * * *表示每 6 小时一次。注意它是字符串传值时需要加引号--set cronjob.schedule0 6 * * *。cronjob.concurrencyPolicy默认Forbid当上一次扫描尚未结束、下一个调度点又到来时的处理策略可选Allow允许并发、Forbid跳过本次不创建新 Job、Replace终止旧 Job 并创建新 Job。默认Forbid对扫描类任务是合理选择可避免两个 kube-hunter 实例同时扫描造成结果混乱。cronjob.failedJobsHistoryLimit/cronjob.successfulJobsHistoryLimit默认均为1分别控制保留的失败 Job 与成功 Job 数量避免历史 Job 及其 Pod 无限堆积。默认各保留 1 个若要长期审计扫描记录可适当调大。cronjob.annotations/pod.annotations默认均为{}分别附加到 CronJob 对象与 Job 的 Pod 模板上常用于注入监控、备份、策略类注解如 Prometheus 抓取注解、自定义 owner 标记。image.repository默认aquasec/kube-hunter容器镜像仓库地址。image.tag默认312镜像 tag与 Chart.yaml 的appVersion: 312保持一致。需要说明的是这是仓库内固定的默认值是否仍是最新版本应以镜像仓库实际发布为准。image.pullPolicy默认IfNotPresent镜像拉取策略。若显式指定image.taglatest建议同步改为Always确保每次拉取最新镜像。customArguments默认[]追加传给 kube-hunter 的额外命令行参数。在 templates/cronjob.yaml 中这些参数会被渲染到--pod之后的 args 列表里例如可传入--remote相关的探针选项或自定义报告参数。注意必须使用 YAML 列表形式传入--set-array或自定义 values 文件例如customArguments: - --quietresources默认{}容器的 CPU / 内存 requests 与 limits。默认不设置任何资源约束values.yaml 注释明确说明这是有意为之——把资源规格的选择权留给用户同时能提高在 Minikube 等小资源环境下的安装成功率。若要限制可按如下结构配置resources: limits: cpu: 100m memory: 128Mi requests: cpu: 100m memory: 128MipriorityClassName默认nil/空Pod 的优先级类名仅在设置后才会渲染进 Pod 模板模板中使用{{- if .Values.priorityClassName }}做条件判断。可用于让扫描任务在资源紧张时获得更高或更低的调度优先级。4.2 模板支持但默认 values 未声明的参数细读 templates/cronjob.yaml 末尾会发现模板还预留了三个通过with块条件渲染的调度控制参数README 表格与默认 values.yaml 中均未声明未声明即为空值渲染时自动跳过nodeSelector将扫描 Pod 固定调度到带指定标签的节点affinity节点/Pod 亲和与反亲和规则tolerations容忍度允许 Pod 调度到带污点的节点。此外templates/_helpers.tpl 中还支持nameOverride与fullnameOverride用于覆盖资源命名后面第五节会详细说明。这些参数都可以通过--set或自定义 values 文件注入属于模板已实现、文档未列出的隐藏能力。五、模板源码级解析values 如何渲染成 CronJob5.1 CronJob 主模板templates/cronjob.yaml整个 Chart 只有一个资源模板逻辑清晰可按下述顺序理解其渲染过程资源类型apiVersion: batch/v1beta1、kind: CronJob。注意这是模板中写死的 API 版本见 cronjob.yaml对应 Chart 发布年代的 Kubernetes 版本在较新的集群上batch/v1beta1已被移除这是使用本 Chart 时需要重点评估的兼容性限制之一。元数据名称由 helperkube-hunter.fullname生成labels 包含app、chart、release、heritage四个标准标签其中app与release同时用于后续 Job 的清理选择器见 NOTES.txt 的删除命令cronjob.annotations通过toYaml ... | indent 4渲染进 CronJob 的 annotations。调度规格schedule直接取自cronjob.scheduleconcurrencyPolicy、failedJobsHistoryLimit、successfulJobsHistoryLimit均使用with块值非空时才渲染。Job 模板jobTemplate包含一层 Job 的 metadata.labelsapprelease其 Pod 模板也打上同样的标签便于按标签批量查询/清理。Pod 规格restartPolicy: Never若设置了priorityClassName则渲染容器名为{{ .Chart.Name }}即kube-hunter镜像为repository:tag拼接args 固定为--pod再加customArguments的 YAML 展开resources与pod.annotations均通过toYaml透传。调度扩展nodeSelector、affinity、tolerations三个with块为可选能力配置了才输出对应字段。这一模板充分体现了 Helm 的惯用写法toYamlindent透传结构化配置、with块做空值守卫、helper 统一生成名称与标签用户几乎不需要理解模板逻辑只改 values 即可完成全部定制。5.2 命名辅助函数templates/_helpers.tpl该文件定义了三个标准 helperkube-hunter.name资源基础名。优先取nameOverride否则取 Chart 名经trunc 63 | trimSuffix -处理保证符合 Kubernetes DNS 名称规范最长 63 字符。kube-hunter.fullname完整资源名。若设置了fullnameOverride直接使用否则取 Chart 名若 release 名已包含该名字则直接复用 release 名避免出现kube-hunter-kube-hunter这类重复命名否则拼接为release-chart同样做 63 字符截断与尾部-清理。kube-hunter.chartChart 标签值格式为Chart 名-版本并把版本中的替换为_Helm chart 版本可能包含metadata后缀而不是合法的 Kubernetes label 字符。这些 helper 是理解 CronJob 名称如my-release-kube-hunter与资源标签来源的关键。5.3 安装提示模板templates/NOTES.txtNOTES.txt 渲染了三条使用须知调度时间按 UTC 理解、Job 历史保留数量、以及卸载后手动清理 Job 的命令。从源码细节看此处存在一个可观察的层级不一致NOTES.txt 中引用的是顶层.Values.failedJobsHistoryLimit与.Values.successfulJobsHistoryLimit而 values.yaml 实际定义在cronjob子键下cronjob.failedJobsHistoryLimit等因此该提示中的数字可能渲染为空。这一现象不影响 CronJob 本身的正确渲染模板用的是正确的cronjob.*路径但说明 NOTES.txt 相对模板更新滞后属于仓库中已存在的小瑕疵。六、查看扫描结果与清理历史 Job6.1 查看扫描结果安装后先确认 CronJob 已创建$ kubectl get cronjob -l appkube-hunterCronJob 默认每天触发一次若要立即验证或手动触发一次扫描可以借助 Kubernetes 的create job --from临时生成一个 Job$ kubectl create job --fromcronjob/release-kube-hunter kube-hunter-manual随后查看该 Job 对应 Pod 的日志kube-hunter 的扫描结论发现的漏洞/攻击路径、风险级别等即输出于此$ kubectl get pods -l appkube-hunter $ kubectl logs pod-name6.2 清理历史 JobNOTES.txt 特别强调删除 Helm release 时CronJob 已产生的历史 Job 及其 Pod 不会被自动删除需要手动按标签清理官方给出的命令为$ kubectl -n namespace delete job -l appkube-hunter,releaserelease即 NOTES.txt 中kubectl delete job -l app...,release...的实际形态。如果你希望保留扫描记录也可以在卸载前先把 Job 的日志导出归档。七、使用注意事项与限制汇总综合仓库内文档与源码使用本 Chart 前建议确认以下几点Chart 已弃用deprecated: true已写入 Chart.yamlREADME 亦有专门声明本 Chart 不再获得维护更新API 版本兼容性模板固定使用batch/v1beta1的 CronJob API见 cronjob.yaml该版本在较新的 Kubernetes 发行版中已被移除部署前需确认目标集群仍支持默认镜像 tag 固定为312若需跟踪 kube-hunter 更新应通过image.tag与image.pullPolicy显式覆盖时区语义cronjob.schedule按 UTC 解析非本地时区文档中的历史遗留README 参数表标题误写为 docker-registry chart、values.yaml 头部注释沿用了其他 Chart 的模板文案均属于仓库自身的复制粘贴遗留不影响渲染结果但阅读时需留意扫描视角Pod 模式下 kube-hunter 以集群内工作负载身份运行其探测范围与集群网络模型、RBAC 权限相关安全团队在评估结果时应结合这一视角理解。八、小结stable/kube-hunter是一个小而完整的 Helm Chart 范本一个 CronJob 模板、一份 values、三个 helper即可把 kube-hunter 的 Pod 模式安全扫描固化为集群内每天自动执行的定时任务。通过本文你可以依据 README.md 的完整参数表熟练定制调度计划、并发策略、镜像与资源通过 templates/cronjob.yaml 与 _helpers.tpl 理解 Helm 模板的toYaml/with/helper 渲染模式甚至基于此结构自行维护一个不依赖弃用 Chart 的 kube-hunter 定时扫描方案。赞分享【免费下载链接】charts⚠️(OBSOLETE) Curated applications for Kubernetes项目地址https://gitcode.com/gh_mirrors/chart/charts点击查看免费下载相关推荐Kubernetes安全扫描工具kube-hunter完全指南Kubernetes安全扫描工具kube hunter完全指南 什么是kube hunter kube hunter是一款由Aqua Security开发的开源应用安全漏洞扫描云原生网络安全如何快速上手DeepLearning10分钟搭建你的第一个深度信念网络如何快速上手DeepLearning10分钟搭建你的第一个深度信念网络 DeepLearning是一个支持Python、C、C、Java、Scala和GoTRIBE v2模型架构深度解析从多模态输入到大脑皮层映射的完整流程TRIBE v2模型架构深度解析从多模态输入到大脑皮层映射的完整流程 TRIBE v2是Meta推出的 多模态脑编码模型 能够精准预测人类在接收自然刺激视创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考