kube-rbac-proxy 源码解析一次 RBAC 授权请求背后的设计哲学【免费下载链接】kube-rbac-proxyKubernetes RBAC authorizing HTTP proxy for a single upstream.项目地址: https://gitcode.com/gh_mirrors/ku/kube-rbac-proxykube-rbac-proxy 源码解析是理解 Kubernetes 安全体系的一条捷径。这个由 Red Hat 工程师 Frederic Branczyk 发起的开源项目是一个针对单一上游服务的小型 HTTP 代理它把 Kubernetes 原生的 RBAC 授权能力下沉到每个 Pod 的 sidecar 中。当你在集群里保护 Prometheus 指标端点、或者为内部服务做精细化访问控制时它都是最轻量、最优雅的解法之一。本文将以一次请求的完整生命周期为主线带你拆解 kube-rbac-proxy 的核心源码看懂它是如何用 Kubernetes 官方 API 完成认证 授权 转发三件事的。为什么需要它RBAC 授权的最后一公里先看一个真实场景Prometheus 要抓取 node-exporter 的指标但集群里任何 Pod 都能通过网络访问它。NetworkPolicy 虽能限制流量却存在明显的短板NetworkPolicy 的局限说明可用性受限部分云厂商、安装器并不支持HostNetwork 绕过开启宿主机网络的 Pod 不受管控无法识别身份只能控制谁能访问不能控制谁能以什么权限访问而 kube-rbac-proxy 站在业务 Pod 之前只放行持有合法 RBAC 身份的请求真正把网络可达和数据可见分开。这正是它的核心设计哲学用 Kubernetes 自己的授权体系保护 Kubernetes 里的服务。请求生命周期一次 RBAC 授权请求的完整旅程在 kube-rbac-proxy.go 的Run函数里请求会被依次包裹进三层过滤器。一次请求的完整流程如下客户端请求 │ ▼ ① 认证过滤器WithAuthentication→ 你是谁 │ TokenReview / OIDC / mTLS 客户端证书 ▼ ② 授权过滤器WithAuthorization→ 你能做什么 │ SubjectAccessReview 对照 RBAC 规则 ▼ ③ 身份透传WithAuthHeaders→ 告诉上游你是谁 │ ▼ ④ 反向代理转发到 upstream这个洋葱模型出自 pkg/filters/auth.go每一层只专注一件事层与层之间通过context传递认证结果设计干净利落。认证层源码解析三种方式识别你是谁认证逻辑位于 pkg/authn 目录支持三种策略DelegatingTokenReview把携带的 Bearer Token 发给 kube-apiserver 做TokenReview见 delegating.go。它直接复用 k8s.io/apiserver 的DelegatingAuthenticatorConfig连缓存 TTL2 分钟和重试退避都与官方对齐。OIDCJWT通过 oidc.go 验证外部身份提供商签发的 JWT支持自定义 username/groups claim 与前缀隔离。mTLS 客户端证书校验客户端证书的签名 CA并把证书的 CommonName 映射为用户名。认证失败的请求统一返回401 Unauthorized没有中间地带——这是安全组件应有的态度。授权层源码解析SubjectAccessReview 如何工作授权层是整个项目最精彩的部分核心在 pkg/authz/auth.go。它做了两件关键的事第一把 HTTP 请求翻译成 Kubernetes 语义。在 pkg/proxy/proxy.go 的GetRequestAttributes中HTTP 方法被映射为 API 动词HTTP 方法RBAC 动词GETgetPOSTcreatePUTupdatePATCHpatchDELETEdelete第二用 SubjectAccessReview 向 apiserver 提问。构造出的AttributesRecord包含用户、动词、资源、命名空间等字段然后通过SubjectAccessReviewAPI 交给 Kubernetes 的 RBAC 引擎裁决。如果用户在集群中没有对应的 Role/ClusterRole 权限代理直接返回403 Forbidden。值得一提的是项目还内置了一个静态授权器staticAuthorizer对于不想每次都打 apiserver 的场景比如只允许特定用户访问特定路径可以在配置文件中直接声明白名单规则减少 API 负载。过滤器链设计洋葱模型中的顺序哲学WithAuthentication 和 WithAuthorization 的嵌套顺序绝非偶然先认证后授权没有身份授权无从谈起任一环节失败即终止错误信息只返回给客户端不泄露内部细节身份注入 context通过request.WithUser把用户信息放入 context供下游层读取。更巧妙的是WithAuthHeaders过滤器它把用户名和用户组写入X-Remote-User、X-Remote-Groups请求头让上游业务服务也能感知调用者身份实现了认证一次、全链路受益。路径控制与代理最后的闸门path.go 提供了两个互补的开关--allow-paths白名单只有匹配的路径才进入认证授权流程其余一律 404--ignore-paths黑名单匹配的路径直接放行用于健康检查等场景。两者互斥从设计上杜绝了配置歧义。最后通过 Go 标准库httputil.NewSingleHostReverseProxy把已授权的请求转发给上游并支持 h2c、上游 TLS 双向认证等高级配置。工程细节那些被忽略的安全设计TLS 证书热加载pkg/tls/reloader.go 用sync.RWMutex保护证书对定时轮询文件变化证书轮换无需重启进程日志脱敏启动时注册SanitizingFilter防止 token 等敏感信息写入日志默认全拒绝匿名认证被显式禁用Anonymous.Enabled: false宁缺毋滥ServiceAccount Token 安全提示项目文档特别提醒token 认证有被上游冒用的风险高敏感场景建议改用 mTLS。设计哲学总结向 Kubernetes 官方实现致敬通读源码你会发现kube-rbac-proxy 几乎没有自造轮子——认证用 apiserver 的 authenticator 工厂授权用官方的 authorizer 接口连 TLS 配置都对齐 k8s 标准。它的设计哲学可以浓缩为三句话信任 Kubernetes 的决策认证、授权全部委托给 apiserver自己只做守门员每一层只做一件事认证、授权、透传、转发各司其职组合出强大能力默认安全拒绝降级匿名认证禁用、不安全监听废弃、日志脱敏把安全冗余刻进代码。对于想深入 Kubernetes 认证授权机制的开发者kube-rbac-proxy 的代码约几千行 Go是一份绝佳的教科书。你可以通过git clone https://gitcode.com/gh_mirrors/ku/kube-rbac-proxy获取源码从cmd/kube-rbac-proxy/app/kube-rbac-proxy.go的Run函数开始顺着一次请求的旅程体验一场优雅的 RBAC 授权设计。【免费下载链接】kube-rbac-proxyKubernetes RBAC authorizing HTTP proxy for a single upstream.项目地址: https://gitcode.com/gh_mirrors/ku/kube-rbac-proxy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考