Linux Kind / minikube 的本地测试集群安全加固对比

minikube 默认启用不安全配置：对10.0.0.0/8等私有网段跳过tls验证、api server监听0.0.0.0:8443并允许匿名访问、none驱动下root运行kubelet；kind因容器化运行天然规避端口暴露和tls校验风险，但需显式启用podsecurity及设置Namespace标签。

minikube 默认启用了哪些不安全的默认配置

minikube 启动时默认启用 --insecure-registry（对 10.0.0.0/8 等私有网段跳过 TLS 验证），同时默认使用 none 驱动时会以 root 运行 kubelet，且 API Server 监听在 0.0.0.0:8443 并允许匿名访问（--anonymous-auth=true）。这些不是“bug”，而是为快速启动做的妥协。

• 检查方式：kubectl get pod -n kube-system | grep apiserver，再用 minikube ssh -- sudo cat /var/lib/minikube/kubeconfig 查看是否含 insecure-skip-tls-verify: true
• 真实风险点：本地开发机若连公网 Wi-Fi，且未关防火墙，0.0.0.0:8443 可能被局域网其他设备直连；镜像拉取时绕过证书校验，可能被中间人劫持
• 修复动作不是“全关掉”，而是按需收紧：比如只允许 127.0.0.1 访问 API Server，禁用匿名认证，但保留 --insecure-registry 给本地 registry（如 localhost:5000）用

Kind 集群的容器化运行模型天然规避了哪些 minikube 风险

Kind 把整个 kubernetes 控制平面跑在 docker 容器里，节点网络默认是 bridge 模式，API Server 默认只绑定到容器内部网络（如 127.0.0.1:6443），宿主机上不暴露端口 —— 这意味着你得通过 kind get kubeconfig 生成的配置才能访问，且该配置默认启用客户端证书认证，没证书连不上。

• 关键差异：Kind 不需要 --insecure-registry 参数也能拉取本地镜像，因为它通过 kind load docker-image 把镜像直接注入节点容器的 image store，绕过了 registry TLS 校验环节
• 注意陷阱：如果你用 kind create cluster --config 自定义配置，手动加了 extraPortMappings 把 6443 映射到宿主机 0.0.0.0，那就复刻了 minikube 的暴露问题
• 性能影响几乎可忽略：容器间通信比 minikube 的 VM 内核调用多一层 netns 切换，但本地测试场景下延迟差不到 1ms

两个工具对 PodSecurityPolicy / PodSecurity Admission 的支持差异

PodSecurityPolicy 已被废弃，但很多团队还在迁移中；而新式的 PodSecurity Admission（Kubernetes v1.22+ 默认启用）在 Kind 和 minikube 中的行为不一致，容易误判“已加固”。

• minikube v1.30+ 默认启用 PodSecurity 准入插件，但它的 default 配置是 restricted 模式，且 namespace 无显式 label 时不会强制执行 —— 你得手动给 namespace 加 pod-security.kubernetes.io/enforce: restricted
• Kind 默认不启用 PodSecurity，哪怕你用 v1.28+ 镜像，也得在 kind-config.yaml 里显式开启：featureGates: {PodSecurity: true}，否则 kubectl auth can-i use podsecuritypolicies 返回 no 是正常的
• 验证是否真生效：部署一个带 hostNetwork: true 的 Pod，如果被拒绝，说明 restricted 生效；如果成功运行，大概率是 admission 没开或 namespace label 漏了

本地集群安全加固的实操底线清单

别追求“生产级等效”，本地测试集群的安全目标是：防止意外暴露、阻断明显高危行为、避免把漏洞惯性带到 CI 或 staging 环境。

• minikube：启动时加 --apiserver-addr=127.0.0.1:8443 --anonymous-auth=false --insecure-port=0；禁用 none 驱动，改用 docker 驱动（避免 root 运行 kubelet）
• Kind：不用动默认配置就比 minikube 更收敛；唯一要补的是加 namespace label，比如 kubectl label ns default pod-security.kubernetes.io/enforce=restricted
• 共通盲点：kubeconfig 文件权限。minikube 生成的 ~/.kube/config 默认是 644，Kind 的 kind get kubeconfig 输出默认没设权限 —— 必须手动 chmod 600，否则 kubectl 会警告且某些环境直接拒绝加载

安全加固不是开关游戏，最常漏掉的是 kubeconfig 权限和 namespace label —— 这俩不写进脚本，每次重装集群就归零。