kube-rbac-proxy 授權原理深度解讀SubjectAccessReview 是如何工作的【免費下載鏈接】kube-rbac-proxyKubernetes RBAC authorizing HTTP proxy for a single upstream.項目地址: https://gitcode.com/gh_mirrors/ku/kube-rbac-proxykube-rbac-proxy 是一個面向單一上游服務的 Kubernetes RBAC 授權 HTTP 代理其授權核心正是 Kubernetes 的SubjectAccessReviewSAR機制。本文帶你從源碼角度深度解讀 kube-rbac-proxy 工作原理一次 HTTP 請求如何被翻譯成一次 RBAC 授權檢查TokenReview 與 SubjectAccessReview 兩次 API 調用如何協(xié)同以及結果緩存、靜態(tài)授權器、請求重寫等進階機制的真實實現(xiàn)幫你徹底搞懂這套側車代理的授權鏈路。為什么普通服務需要 SubjectAccessReview 代理在默認配置下Kubernetes 集群內任何 Pod 都能訪問其他 Pod 的網絡端口。如果你的應用比如 Prometheus 的 metrics 端點希望只允許持有合法 RBAC 權限的調用方訪問就需要一個門衛(wèi)校驗調用方身份你是誰校驗調用方權限你能做這件事嗎通過后才把請求轉發(fā)給真正的上游應用kube-rbac-proxy 正是扮演這個門衛(wèi)角色。它不自己實現(xiàn)權限判斷而是把判斷委托給 Kubernetes API Server 的 SubjectAccessReview 接口因此你的 RBAC 策略只維護一份規(guī)則完全統(tǒng)一。kube-rbac-proxy 完整工作流程認證 → 授權 → 轉發(fā)一次請求從進入到轉發(fā)需要依次穿過三個過濾器見pkg/filters/auth.go順序至關重要順序過濾器作用失敗返回1WithAuthentication身份認證401 Unauthorized2WithAuthorizationRBAC 授權403 Forbidden3WithAuthHeaders注入用戶信息到請求頭—在入口處cmd/kube-rbac-proxy/app/kube-rbac-proxy.go的Run函數(shù)處理器會按照WithAuthHeaders → WithAuthorization → WithAuthentication的順序層層包裹也就是先認證、再授權、最后才放行。此外--ignore-paths配置的路徑可以完全跳過認證授權直接轉發(fā)。第一次 API 調用TokenReview 完成身份認證 當客戶端攜帶 Bearer Token 訪問時kube-rbac-proxy 調用authentication.k8s.io的TokenReview接口把 token 交給 API Server 校驗簽名、有效期和 audiences換取一個標準的 Kubernetes 用戶對象用戶名 組。這一邏輯位于pkg/authn/delegating.go通過authenticatorfactory.DelegatingAuthenticatorConfig構建其中匿名訪問被強制關閉Anonymous.Enabled falseTokenReview 結果緩存 2 分鐘CacheTTL如果配置了--client-ca-file客戶端 TLS 證書也是合法的認證方式認證成功后用戶對象被寫入請求上下文供下一步授權使用。第二次 API 調用SubjectAccessReview 完成授權 ?認證通過后kube-rbac-proxy 調用authorization.k8s.io的SubjectAccessReview接口把用戶 請求屬性打包發(fā)送給 API Server由 API Server 基于 RBAC 規(guī)則做出 Allow / Deny / NoOpinion 的判斷。創(chuàng)建 SAR 授權器的核心代碼在pkg/authz/auth.go的NewSarAuthorizer設置SubjectAccessReviewClient指向 Authorization V1 接口允許結果緩存 5 分鐘AllowCacheTTL拒絕結果緩存 30 秒DenyCacheTTL正是這兩個緩存 TTL讓高頻請求不必每次都打到 API Server性能大幅提升。SubjectAccessReview 的關鍵請求如何被翻譯成授權屬性 API Server 只認 RBAC 屬性不認識 HTTP 請求。kube-rbac-proxy 的核心魔法就在pkg/proxy/proxy.go的GetRequestAttributes把 HTTP 請求翻譯成authorizer.Attributes。HTTP 方法到 RBAC 動詞的映射表HTTP 方法RBAC 動詞POSTcreateGETgetPUTupdatePATCHpatchDELETEdelete其他*任意資源請求與非資源請求RBAC 授權區(qū)分兩類請求非資源請求不配置resourceAttributes時代理直接使用 URL 路徑如/metrics構造屬性對應 RBAC 中的nonResourceURLs規(guī)則。資源請求配置resourceAttributes后通過 namespace、apiGroup、resource、subresource、name 構造屬性對應 RBAC 中的resources規(guī)則。例如examples/resource-attributes示例中要求調用方對 Servicekube-rbac-proxy擁有services/proxy子資源的get權限SAR 請求就會攜帶這組資源屬性去校驗。雙保險靜態(tài)授權器與 SAR 授權器如何疊加 ?細心的讀者會發(fā)現(xiàn)Run函數(shù)中創(chuàng)建了兩個授權器并通過union.New組合靜態(tài)授權器NewStaticAuthorizer在本地配置里做精確匹配支持用戶名、動詞、命名空間、資源、路徑等字段全部匹配才放行。命中即返回 Allow不命中返回 NoOpinion不會拒絕。SAR 授權器NewSarAuthorizer走 SubjectAccessReview 委托 API Server 判斷。兩個授權器按先靜態(tài)、后 SAR的順序求并集只要其中一個允許請求就放行。這種設計既支持純本地白名單性能最好也支持完全交給 Kubernetes RBAC 管理策略最統(tǒng)一。高級配置按請求重寫 SubjectAccessReview ??kube-rbac-proxy 還支持根據(jù)請求參數(shù)動態(tài)改寫 SAR 內容見examples/rewrites示例適用于多租戶場景rewrites.byQueryParameter從 URL 查詢參數(shù)取值rewrites.byHTTPHeader從請求頭取值resourceAttributes中支持 Go 模板{{ .Value }}把參數(shù)值注入屬性字段比如把 URL 中的?namespacefoo映射到 SAR 的 namespace 字段這樣同一個代理就可以服務不同命名空間的授權校驗靈活度極高。部署前必看的 RBAC 權限配置 kube-rbac-proxy 自身需要兩個 API 的創(chuàng)建權限才能工作rules: - apiGroups: [authentication.k8s.io] resources: [tokenreviews] verbs: [create] - apiGroups: [authorization.k8s.io] resources: [subjectaccessreviews] verbs: [create]完整可運行的 Deployment、Service、ConfigMap 與 RBAC 清單可以直接參考examples/resource-attributes/deployment.yaml和examples/rewrites/deployment.yaml。另外提醒一句使用 Token 認證時接收方可以冒充調用方身份。請只在調用方 token 權限足夠低、或接收方權限本身更高的情況下使用 Token 認證生產環(huán)境更推薦 mTLS 客戶端證書方案。總結理解 SubjectAccessReview 是掌握 kube-rbac-proxy 的關鍵 回顧全文kube-rbac-proxy 的授權原理可以濃縮為一句話它把HTTP 請求翻譯成RBAC 屬性再通過 SubjectAccessReview 委托 API Server 裁決并輔以靜態(tài)白名單和結果緩存來提升性能與靈活性。認證靠TokenReview你是誰授權靠SubjectAccessReview你能做什么屬性翻譯邏輯在pkg/proxy/proxy.go授權器在pkg/authz/auth.go過濾器鏈在pkg/filters/auth.go允許緩存 5 分鐘、拒絕緩存 30 秒是性能優(yōu)化的關鍵參數(shù)掌握了這條鏈路你就能自信地在生產集群里部署 kube-rbac-proxy并針對業(yè)務場景定制資源屬性與重寫規(guī)則了。如果你正準備保護自己的 metrics 端點或內部服務不妨按照上面的流程親手搭建一遍感受一次認證、二次授權的完整閉環(huán)。【免費下載鏈接】kube-rbac-proxyKubernetes RBAC authorizing HTTP proxy for a single upstream.項目地址: https://gitcode.com/gh_mirrors/ku/kube-rbac-proxy創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 kube-rbac-proxy 授權原理深度解讀：SubjectAccessReview 是如何工作的？
kube-rbac-proxy 授權原理深度解讀SubjectAccessReview 是如何工作的【免費下載鏈接】kube-rbac-proxyKubernetes RBAC authorizing HTTP proxy for a single upstream.項目地址: https://gitcode.com/gh_mirrors/ku/kube-rbac-proxykube-rbac-proxy 是一個面向單一上游服務的 Kubernetes RBAC 授權 HTTP 代理其授權核心正是 Kubernetes 的SubjectAccessReviewSAR機制。本文帶你從源碼角度深度解讀 kube-rbac-proxy 工作原理一次 HTTP 請求如何被翻譯成一次 RBAC 授權檢查TokenReview 與 SubjectAccessReview 兩次 API 調用如何協(xié)同以及結果緩存、靜態(tài)授權器、請求重寫等進階機制的真實實現(xiàn)幫你徹底搞懂這套側車代理的授權鏈路。為什么普通服務需要 SubjectAccessReview 代理在默認配置下Kubernetes 集群內任何 Pod 都能訪問其他 Pod 的網絡端口。如果你的應用比如 Prometheus 的 metrics 端點希望只允許持有合法 RBAC 權限的調用方訪問就需要一個門衛(wèi)校驗調用方身份你是誰校驗調用方權限你能做這件事嗎通過后才把請求轉發(fā)給真正的上游應用kube-rbac-proxy 正是扮演這個門衛(wèi)角色。它不自己實現(xiàn)權限判斷而是把判斷委托給 Kubernetes API Server 的 SubjectAccessReview 接口因此你的 RBAC 策略只維護一份規(guī)則完全統(tǒng)一。kube-rbac-proxy 完整工作流程認證 → 授權 → 轉發(fā)一次請求從進入到轉發(fā)需要依次穿過三個過濾器見pkg/filters/auth.go順序至關重要順序過濾器作用失敗返回1WithAuthentication身份認證401 Unauthorized2WithAuthorizationRBAC 授權403 Forbidden3WithAuthHeaders注入用戶信息到請求頭—在入口處cmd/kube-rbac-proxy/app/kube-rbac-proxy.go的Run函數(shù)處理器會按照WithAuthHeaders → WithAuthorization → WithAuthentication的順序層層包裹也就是先認證、再授權、最后才放行。此外--ignore-paths配置的路徑可以完全跳過認證授權直接轉發(fā)。第一次 API 調用TokenReview 完成身份認證 當客戶端攜帶 Bearer Token 訪問時kube-rbac-proxy 調用authentication.k8s.io的TokenReview接口把 token 交給 API Server 校驗簽名、有效期和 audiences換取一個標準的 Kubernetes 用戶對象用戶名 組。這一邏輯位于pkg/authn/delegating.go通過authenticatorfactory.DelegatingAuthenticatorConfig構建其中匿名訪問被強制關閉Anonymous.Enabled falseTokenReview 結果緩存 2 分鐘CacheTTL如果配置了--client-ca-file客戶端 TLS 證書也是合法的認證方式認證成功后用戶對象被寫入請求上下文供下一步授權使用。第二次 API 調用SubjectAccessReview 完成授權 ?認證通過后kube-rbac-proxy 調用authorization.k8s.io的SubjectAccessReview接口把用戶 請求屬性打包發(fā)送給 API Server由 API Server 基于 RBAC 規(guī)則做出 Allow / Deny / NoOpinion 的判斷。創(chuàng)建 SAR 授權器的核心代碼在pkg/authz/auth.go的NewSarAuthorizer設置SubjectAccessReviewClient指向 Authorization V1 接口允許結果緩存 5 分鐘AllowCacheTTL拒絕結果緩存 30 秒DenyCacheTTL正是這兩個緩存 TTL讓高頻請求不必每次都打到 API Server性能大幅提升。SubjectAccessReview 的關鍵請求如何被翻譯成授權屬性 API Server 只認 RBAC 屬性不認識 HTTP 請求。kube-rbac-proxy 的核心魔法就在pkg/proxy/proxy.go的GetRequestAttributes把 HTTP 請求翻譯成authorizer.Attributes。HTTP 方法到 RBAC 動詞的映射表HTTP 方法RBAC 動詞POSTcreateGETgetPUTupdatePATCHpatchDELETEdelete其他*任意資源請求與非資源請求RBAC 授權區(qū)分兩類請求非資源請求不配置resourceAttributes時代理直接使用 URL 路徑如/metrics構造屬性對應 RBAC 中的nonResourceURLs規(guī)則。資源請求配置resourceAttributes后通過 namespace、apiGroup、resource、subresource、name 構造屬性對應 RBAC 中的resources規(guī)則。例如examples/resource-attributes示例中要求調用方對 Servicekube-rbac-proxy擁有services/proxy子資源的get權限SAR 請求就會攜帶這組資源屬性去校驗。雙保險靜態(tài)授權器與 SAR 授權器如何疊加 ?細心的讀者會發(fā)現(xiàn)Run函數(shù)中創(chuàng)建了兩個授權器并通過union.New組合靜態(tài)授權器NewStaticAuthorizer在本地配置里做精確匹配支持用戶名、動詞、命名空間、資源、路徑等字段全部匹配才放行。命中即返回 Allow不命中返回 NoOpinion不會拒絕。SAR 授權器NewSarAuthorizer走 SubjectAccessReview 委托 API Server 判斷。兩個授權器按先靜態(tài)、后 SAR的順序求并集只要其中一個允許請求就放行。這種設計既支持純本地白名單性能最好也支持完全交給 Kubernetes RBAC 管理策略最統(tǒng)一。高級配置按請求重寫 SubjectAccessReview ??kube-rbac-proxy 還支持根據(jù)請求參數(shù)動態(tài)改寫 SAR 內容見examples/rewrites示例適用于多租戶場景rewrites.byQueryParameter從 URL 查詢參數(shù)取值rewrites.byHTTPHeader從請求頭取值resourceAttributes中支持 Go 模板{{ .Value }}把參數(shù)值注入屬性字段比如把 URL 中的?namespacefoo映射到 SAR 的 namespace 字段這樣同一個代理就可以服務不同命名空間的授權校驗靈活度極高。部署前必看的 RBAC 權限配置 kube-rbac-proxy 自身需要兩個 API 的創(chuàng)建權限才能工作rules: - apiGroups: [authentication.k8s.io] resources: [tokenreviews] verbs: [create] - apiGroups: [authorization.k8s.io] resources: [subjectaccessreviews] verbs: [create]完整可運行的 Deployment、Service、ConfigMap 與 RBAC 清單可以直接參考examples/resource-attributes/deployment.yaml和examples/rewrites/deployment.yaml。另外提醒一句使用 Token 認證時接收方可以冒充調用方身份。請只在調用方 token 權限足夠低、或接收方權限本身更高的情況下使用 Token 認證生產環(huán)境更推薦 mTLS 客戶端證書方案。總結理解 SubjectAccessReview 是掌握 kube-rbac-proxy 的關鍵 回顧全文kube-rbac-proxy 的授權原理可以濃縮為一句話它把HTTP 請求翻譯成RBAC 屬性再通過 SubjectAccessReview 委托 API Server 裁決并輔以靜態(tài)白名單和結果緩存來提升性能與靈活性。認證靠TokenReview你是誰授權靠SubjectAccessReview你能做什么屬性翻譯邏輯在pkg/proxy/proxy.go授權器在pkg/authz/auth.go過濾器鏈在pkg/filters/auth.go允許緩存 5 分鐘、拒絕緩存 30 秒是性能優(yōu)化的關鍵參數(shù)掌握了這條鏈路你就能自信地在生產集群里部署 kube-rbac-proxy并針對業(yè)務場景定制資源屬性與重寫規(guī)則了。如果你正準備保護自己的 metrics 端點或內部服務不妨按照上面的流程親手搭建一遍感受一次認證、二次授權的完整閉環(huán)。【免費下載鏈接】kube-rbac-proxyKubernetes RBAC authorizing HTTP proxy for a single upstream.項目地址: https://gitcode.com/gh_mirrors/ku/kube-rbac-proxy創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考