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 —— 这俩不写进脚本，每次重装集群就归零。
