Current Limitations of User Authorization - stolostron/search-v2-operator GitHub Wiki

User data collection:

Before authorization, the search api will collect and cache resources that exist for all users (shared data cache). Search api will collect cluster-scoped resources (via database queries), namespace-scoped resources and managed clusters (via Kube client call). This cache has an expiration after n mins.

SSRR & SSAR Kube-API requests

In the current implementation of search-v2-api, we need to make a lot of calls to Kubernetes apis, SelfSubjectRulesReview (for namespace-scoped-resources) and the SelfSubjectAccessReview (for cluster-scoped-resources), in order to get user access/rules. This can cause overload on search api because as the number of namespaces increase so do the amount of SSRR calls and similarly with cluster scoped resources and SSAR calls. This makes our logic complex as well and inefficient.

Caching user data:

We only authorize the user the first time they make a request (the user is identified based on the user id that comes from the token review response during the authentication step which is also cached). We cache the user's authorized cluster-scoped-resources, namespace-scoped resources (on hub where user has list access) and managed clusters (where the user has view access). This cache is referenced every time the user makes a request during the session while the user id is valid (we re-validate the token after 1 min currently). The user data cache expires every n min regardless if the token is valid and so we re-authorize the user every n min.

RBAC Query

The resources and managed clusters the user has access to will get appended to the search query. This can grow very large.

ex: if user has access to 1000 resources (1000 kinds & 1000 apigroups) the query can be

select uid, cluster, data from search.resources where (apigroup = n and kind = m) and (apigroup = n+1 and kind = m+1) .... and (apigroup = n+999 and kind = m+99)