零信任服务鉴权在go中必须每次请求、每个服务节点都重新验证身份+上下文+策略，拒绝默认信任任何来源；jwt解析需严格校验issuer、expiresat、密钥安全及spiffe id，rbac须结合method与path细粒度控制，pep与pdp须物理分离且fail-closed。
零信任服务鉴权在 Go 中不能只靠一个中间件或一次 JWT 解析就完事——它必须是「每次请求、每个服务节点」都重新验证身份+上下文+策略，且拒绝默认信任任何来源（包括 localhost、k8s Pod IP、同一 namespace 下的服务）。
JWT 解析必须绑定可信签发方与明确过期策略
仅用 jwt.ParseWithClaims 不够，关键在于校验逻辑是否严格：
- 必须显式检查
token.Claims.(*Claims).Issuer是否匹配预期值（如"auth-service.prod"），防止测试环境密钥被用于生产 -
ExpiresAt必须用jwt.NewNumericDate()而非time.Now().Unix()，避免时钟漂移导致误判 - 签名密钥绝不能硬编码；生产环境应通过环境变量注入，并在启动时校验长度（HMAC-SHA256 要求至少 32 字节，否则降级为弱密钥）
- 若使用 RSA/EdDSA，需预加载公钥并校验
token.Header["kid"]与密钥 ID 匹配，支持密钥轮换
RBAC 权限检查不能只查角色，必须结合资源路径与 HTTP 方法
常见错误是把 rolePermissions["admin"] 当作万能钥匙，实际会漏掉细粒度控制：
- 权限判断函数如
CheckPermission(role, action string)应扩展为CheckPermission(role, method, path string) - 例如
GET /api/users/me和DELETE /api/users/123是两个完全不同的权限项，不能共用"user:read" - 建议用路径前缀匹配（如
/api/orders/*）而非全等，但需注意通配符优先级和重叠规则的冲突处理 - 策略缓存需带 TTL（如 5 分钟），且支持热更新通知（如监听 etcd 或 Redis Pub/Sub）
服务间通信必须启用双向 TLS（mTLS）并校验证书 SPIFFE ID
光靠 JWT 无法防止服务伪造——攻击者拿到一个合法 token 后可直接调用下游服务。真正零信任要求链路层身份：
- 每个微服务启动时加载由 SPIRE Server 签发的 X.509 证书，证书中
URI SAN字段必须为spiffe://domain.test/ns/default/svc/my-service - HTTP 客户端必须设置
tls.Config.VerifyPeerCertificate回调，提取并校验该 URI 值是否在白名单内 - 网关或服务端需同时验证：① TLS 客户端证书有效；② JWT 中的
service_id字段与证书 URI 一致；③ 两者所属 trust domain 相同 - Go 标准库不自动解析 SPIFFE URI，需手动调用
cert.URIs并做字符串比对（注意大小写与 scheme 规范）
策略执行点（PEP）必须与策略决策点（PDP）物理分离
把 RBAC 规则硬编码进服务代码等于放弃动态管控能力：
- PEP（如 Gin 中间件）只负责提取请求上下文（method、path、header、client cert、JWT claims）并转发给独立 PDP 服务
- PDP 应提供 gRPC 接口，输入结构体含
Subject（用户/服务身份）、Resource（路径+方法）、Context（IP、时间、设备指纹等） - 禁止在 PEP 中调用数据库或 Redis 查询权限——所有策略数据应在 PDP 内部缓存，PEP 只做低延迟转发
- 超时必须设为 ≤200ms，失败默认拒绝（fail-closed），避免因 PDP 故障导致越权放行
最易被忽略的是「上下文漂移」：同一个 JWT 在不同服务节点上可能被解析出不同 Claims（比如时钟不同步导致 NotBefore 判定失败），或 mTLS 证书在负载均衡后丢失。真正在生产落地时，得把时间同步、证书透传、策略一致性校验做成基础设施级检查项，而不是写在某段 Go 代码里。
