--active模式真实发起攻击性探测，如连接Kubernetes API Server未授权端口、向kubelet发/pods或/exec请求、探测etcd暴露等；被动模式仅依赖DNS解析、TLS证书、HTTP响应头等已暴露信息。
主动模式（--active）到底扫哪些东西
它会真实发起攻击性探测，比如尝试连接 Kubernetes API Server 的未授权端口、暴力猜测 service account token、向 kubelet 发起 /pods 或 /exec 请求、尝试挂载 hostPath 卷、探测 etcd 是否暴露在公网——这些操作都可能触发告警、写入日志甚至中断服务。
实操建议：
- 只在测试环境或你有明确授权的集群上运行
kube-hunter --active - 避免在生产集群的 master 节点所在网段直接执行，防止被网络策略拦截或触发安全设备响应
-
--active默认不爆破凭证，但会尝试利用已知默认配置（如anonymous用户权限、insecure-port开启等）
被动模式（默认）实际依赖什么信息
它不发任何请求，只靠 DNS 解析、TLS 证书信息、HTTP 响应头、公开端口扫描（不发 payload）、以及对 kubernetes.default.svc 域名能否解析的判断来推测架构。换句话说：它看得到的，仅限于你“已经暴露出去”的那部分表象。
常见错误现象：
- 集群内网部署，DNS 不对外，
kube-hunter在外部跑，连kubernetes.default.svc都解析失败 → 直接退出，不报任何漏洞 - API Server 启用了 TLS 但证书是自签的，被动模式会记录 “could not verify certificate”，但不会进一步尝试握手
- 误以为“没报高危 = 安全”，其实只是它压根没看到你的 kubelet 端口（比如被防火墙挡了）
--active 和被动模式在攻击面覆盖上的本质差异
被动模式回答的是：“从外部看，这个集群像不像有漏洞？”；--active 回答的是：“如果我是一个已有基础访问权限的攻击者，现在能走多远？”
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
关键区别点：
- 被动模式无法发现需认证后才能触发的问题（如 RBAC 配置过宽、
podSecurityPolicy绕过），--active会尝试用匿名 token 或默认 service account 去调用 -
--active会检测本地提权路径（如hostPath挂载/etc/kubernetes），被动模式完全看不到容器运行时配置 - 某些插件式组件（如 kubefed、karmada）的接口，被动模式基本忽略，
--active可能通过 endpoint 列表识别并探测
别被 --active 的“高危”结果带偏节奏
它报出的 Privilege Escalation via kubelet /exec 或 etcd exposed 类问题，往往依赖具体上下文：API Server 是否开启了 --anonymous-auth=true、kubelet 是否禁用了 --read-only-port、etcd 是否绑定了 0.0.0.0 而非 127.0.0.1。
容易踩的坑：
- 在 minikube 或 kind 集群里跑
--active，几乎必报一堆“高危”，但这只是开发环境默认配置宽松，不等于线上也会这样 - 没关掉
--insecure-port就上线，--active会立刻打穿，但被动模式根本发现不了这个端口是否存在 - 用
--active扫完就以为万事大吉，却漏掉了 CI/CD 流水线中硬编码的 token、或 Helm chart 里写死的hostPath—— 这些不在运行时攻击面里，但一样致命
真正难判断的，从来不是“扫出来几个洞”，而是每个洞背后对应的最小权限边界和横向移动链路是否可控。
