From e020038c2bd91e614ddf66942b6aae4032e794fc Mon Sep 17 00:00:00 2001 From: jwcesign Date: Sun, 4 Jun 2023 15:57:29 +0800 Subject: [PATCH] doc: Add the limitations of search proxy Signed-off-by: jwcesign --- docs/proposals/caching/README.md | 12 ++++++++++++ docs/proposals/resource-aggregation-proxy/README.md | 4 ++++ 2 files changed, 16 insertions(+) diff --git a/docs/proposals/caching/README.md b/docs/proposals/caching/README.md index 7d2fb33ba..e19f29aec 100644 --- a/docs/proposals/caching/README.md +++ b/docs/proposals/caching/README.md @@ -18,6 +18,10 @@ Provides a caching layer for Karmada to cache (member clusters) Kubernetes resou ## Motivation +In multicluster scenario, if the administrators want to query the resource in multiple clusters, it's quite hard and inefficient, including changing the clusters' context, none-global resource view. + +To address this issue, we propose a caching layer for Karmada to cache (member clusters) Kubernetes resources, the administrators could query the resource across multiple clusters efficiently with a unified entry. + ### Goals - Accelerates resource requests processing speed across regions @@ -43,6 +47,12 @@ Goals: - Accelerate processing speed of resource requests across regions. - Get resources in multiple clusters by labels. +### Risks and Mitigations + +1. This feature aims to build a cache to store arbitrary resources from multiple member clusters. And these resources are exposed by `search/proxy` REST APIs. If a user has access privilege to `search/proxy`, they can directly access the cached resource without routing their request to the member clusters. +1. As previously mentioned, the resource query request will not be routed to the member clusters. So if a secret is cached in the Karmada control plane but a user in the member cluster cannot access it via member cluster's apiserver due to RBAC privilege limitations, they can still access the secret through the Karmada control plane. +1. This feature is designed for administrators who needs to query and view the resources in multiple clusters, not designed for the end users. Exposing this API to the end users may cause end users to be able to view resources that do not belong to them. + ## Design Details ### Define the scope of the cached resource @@ -188,4 +198,6 @@ spec: apiVersion: apps/v1 ``` +With this `ResourceRegistry`, Karmada will list and watch the resource defined in `spec.resourceSelectors` and caches the real-time manifest in the cache(local memory or database), and all the query results are from the cache. + ### Test Plan diff --git a/docs/proposals/resource-aggregation-proxy/README.md b/docs/proposals/resource-aggregation-proxy/README.md index d98cfe3b3..38077fde4 100644 --- a/docs/proposals/resource-aggregation-proxy/README.md +++ b/docs/proposals/resource-aggregation-proxy/README.md @@ -57,7 +57,11 @@ Allow kubernetes API clients (kubectl, client-go, and other clients that use kub ## Non-Goals +## Risks and Mitigations +1. This feature aims to build a cache to store arbitrary resources from multiple member clusters. And these resources are exposed by `search/proxy` REST APIs. If a user has access privilege to `search/proxy`, they can directly access the cached resource without routing their request to the member clusters. +1. As previously mentioned, the resource query request will not be routed to the member clusters. So if a secret is cached in the Karmada control plane but a user in the member cluster cannot access it via member cluster's apiserver due to RBAC privilege limitations, they can still access the secret through the Karmada control plane. +1. This feature is designed for administrators who needs to query and view the resources in multiple clusters, not designed for the end users. Exposing this API to the end users may cause end users to be able to view resources that do not belong to them. # Proposal