Harbor本身不拦截流量，防御依赖项目级权限、自动扫描、签名验证和推送前策略拦截；需设项目为私有、启用预扫描与内容信任、限制推送角色，并在CI中强制签名验证。
Harbor 不是“防御通道”，它本身不拦截或过滤镜像流量；真正起防御作用的是你如何配置它的策略链——包括项目级权限、自动扫描、签名验证和推送前策略拦截。直接把 Harbor 当成防火墙用，会漏掉关键攻击面。
Harbor 项目级权限与镜像推送拦截必须开启
默认安装的 Harbor 允许任意用户向公开项目推送镜像，这等于把仓库大门敞开。防御的第一道关卡是项目（Project）级别的策略控制。
- 创建项目时务必勾选
Public→Private，避免匿名写入 - 在项目设置中启用
Pre-scan vulnerability：镜像推送时触发 Trivy 扫描，扫描失败则拒绝入库（需提前配置扫描器并确保 Job Service 正常） - 开启
Content trust（即 Notary 或 Cosign 集成）：要求所有推送镜像必须带有效签名，否则403 Forbidden - 限制推送者角色：仅允许
Developer或自定义角色推送，Guest角色只能拉取
Golang 构建阶段强制签名：Cosign + CI 流水线绑定
防御不能只靠 Harbor 拦截，得从源头让恶意/未授权镜像根本造不出来。Golang 微服务构建完成后，必须签名再推送。
- CI 中构建完镜像后执行：
cosign sign --key cosign.key $IMAGE_REF，密钥建议存于 Vault 或 K8s Secret - 推送前验证签名有效性：
cosign verify --key cosign.pub $IMAGE_REF，失败则中断流水线 - 注意
$IMAGE_REF格式必须含完整 Harbor 地址，如harbor.example.com/proj/api:v1.2.0，否则签名无法被 Harbor 关联识别 - Go 程序自身无需修改，但 CI 脚本里要确保
docker push前已签名，且 Harbor 的项目已启用内容信任
Harbor 镜像拉取侧的 RBAC 与网络隔离
K8s Pod 拉取镜像时，不是“连上 Harbor 就能拿”，而是由 kubelet 使用 secret 认证。这里容易忽略两点：
立即学习“go语言免费学习笔记（深入）”；
- ServiceAccount 绑定的
imagePullSecret必须对应 Harbor 中有Pull权限的用户，不能复用管理员账号 - Harbor 后端 Registry 的访问路径（通常是
/service/token）必须被 K8s 节点网络可达，若用了 Ingress，需确认 Nginx 配置未截断Authorization头 - 生产环境建议将 Harbor 部署在独立 namespace，并通过 NetworkPolicy 限制仅 K8s control plane 和 build agent 网段可访问其
core和registry服务端口
Nginx 超时与大镜像传输的隐性安全风险
Harbor 的 Nginx 默认 proxy_read_timeout 是 60 秒。当 Golang 微服务镜像因含模型权重或调试符号体积超 2GB 时，拉取可能卡在 504，导致部分 Pod 启动失败——但这不是功能问题，而是暴露了策略盲区。
- 不要简单调高 timeout，先检查镜像是否真的需要这么大：用
docker history $IMAGE查看层体积，删掉go mod download缓存等中间产物 - 若确需大镜像，调整 ConfigMap 中
nginx.conf的proxy_read_timeout和proxy_send_timeout至 900（15 分钟），并重启harbor-nginxPod - 更关键的是：超时期间镜像数据仍在传输，但 Harbor 未完成校验就断连，可能留下不完整 manifest——此时应配合
registry garbage collection定期清理
真正的防御不在 Harbor 界面开关里，而在你是否让每个镜像都经过“构建→签名→扫描→权限校验→拉取认证”这条闭环。漏掉任意一环，比如跳过签名直接推送，或用 admin token 拉取，整条链就形同虚设。
