kubelet 端口风险是什么
kubelet 是每个 Kubernetes 节点上的核心组件，负责起停容器与上报状态，并在 10250 端口提供 HTTPS API（/pods、/logs、/exec 等）。它的默认配置对匿名请求较宽松：若 --anonymous-auth 保持开启且授权模式不是 Webhook，未认证请求就可能读取节点上 Pod 的元数据与日志。旧版本还存在明文只读端口 10255，同样需要确认已关闭。
基本信息
| 服务 | kubelet（节点组件） |
|---|---|
| 端口 | 10250（HTTPS API）；10255（旧只读端口，已废弃） |
| 关键参数 | --anonymous-auth=false、--authorization-mode=Webhook、--read-only-port=0 |
| 控制手段 | 网络策略与云安全组限制来源，通常只允许控制面与运维网段 |
边界测试（授权环境内）
边界测试（授权环境内）
curl -sk -o /dev/null -w '%{http_code}\n' https://NODE_IP:10250/healthz # 看是否要求认证
curl -sk https://NODE_IP:10250/pods | head -c 200 # 尝试读取 Pod 列表
# 期望 401/403 或需凭据；能直接返回数据说明认证/授权不足
# 测试须在获批范围内进行，接口内容可能包含敏感配置收敛要点
收敛要点
1. kubelet 参数：--anonymous-auth=false，--authorization-mode=Webhook，--read-only-port=0
2. 10250 仅允许控制面与运维网段访问（云安全组/网络策略）
3. 启用证书轮换（rotateCertificates），避免长期使用同一节点凭据
4. 关注版本公告中 kubelet 相关安全修复并跟随升级
5. 节点上不存放长期高权限 kubeconfig，避免节点失守后直接获得集群管理员权限典型使用场景
- 集群上线前基线检查：逐节点确认匿名认证与授权模式的实际取值
- 暴露面排查：从集群外与其他节点两个视角测试 10250 可达性
- 多租户集群加固：用网络策略限制跨命名空间访问 kubelet
- 事件排查：节点失守后确认攻击者是否通过 kubelet API 读取了其他 Pod 的日志与配置
- 托管集群核查：云上节点池的默认参数需要在节点层验证，不能只看控制台说明
参数与含义
| 参数 | 含义 | 安全取值 |
|---|---|---|
| --anonymous-auth | 是否允许匿名请求 | false |
| --authorization-mode | 授权模式 | Webhook（配合 RBAC） |
| --read-only-port | 明文只读端口 | 0（关闭） |
| --rotate-certificates | 是否轮换客户端证书 | true |
节点端口通常在集群内部署横向可达：把 10250 收敛到控制面，可显著减少节点之间的越权面，也能限制单个 Pod 逃逸后的横向范围。
kubelet API 不只是读接口：/exec、/logs 一类路径在权限足够时能进入容器。匿名认证开启且网络可达的组合，等于给攻击者提供了容器内的执行通道。