Leveraging a single namespace

[patrykorwat]

In the architecture design documentation [1], it is stated that:

Kubernetes has a native soft multi-tenancy isolation in the granularity of its namespace resources, so in OCM, for each of the managed cluster we will be provisioning a dedicated namespace for the managed cluster and grants sufficient RBAC permissions so that the klusterlet can persist some data in the hub cluster.

According to Kubernetes guide [2] on using namespaces, using this K8S feature is an anti-pattern as namespaces concept was not designed for multi-tenancy purpose. It is a responsibility of an application, OCM in this case, to provide multi-tenancy support.

Moreover, this statement comes with an assumption an administrator that is installing OCM, is granted with a permissive ClusterRole, that is, with a ClusterRole that allows operations across all namespaces. K8S RBAC was not designed to support any other type of wildcard-patterns to support sub-namespaces, as described in length in the discussions on resource wildcards [3]. Creation of a new ClusterRole each time a new namespace is needed, adds additional burden to operations that render the project impossible to use in a cluster with single-namespace segregation of services.

Because of this assumption, I recommend reworking the project to require a single namespace for the whole OCM, as it is a general practice across CNCF projects, and it is still early in OCM development, so this change can be done with little impact.

On a side not, this adjustment of core concepts is happening in other infra management projects as well, see crossplane/crossplane#6255 for an analogy.

Ref

1. https://open-cluster-management.io/docs/concepts/architecture/#cluster-namespace
2. https://kubernetes.io/blog/2016/08/kubernetes-namespaces-use-cases-insights/
3. Enhance "resourceNames" field's capability in RBAC Roles to give permissions to all instances of a resource matching some pattern kubernetes/kubernetes#56582

[mikeshng]

Hi @patrykorwat Just giving you an update. Thank you for taking the time to provide such detailed feedback. We're taking extra time to craft a proper response and appreciate your patience. Thanks again!

[mikeshng]

Hi @patrykorwat , thank you again for your patience.

The major reason we dedicate a namespace to each managed cluster is to limit the scope of what a klusterlet agent can access on the hub cluster. Namespaces provide a clear boundary, making sure each agent only has privileges within its own namespace on the hub cluster. The namespace on the hub has a 1-1 relationship with the managed cluster and its agents. Using namespaces is just a natural way of limiting access scope.

We do recognize the need to continuous improvement so we are starting to investigating in some new approaches. We have already implemented a registration driver interface so that new connection models can be adopted in the future.

One of which is the agent registers via a dedicated gRPC server on the hub, instead of connecting directly to the hub's API server. This would potentially remove the requirement for a managedcluster per namespace model because the gRPC endpoint could handle isolation and authorization. See #869

Another one is to explore SPIFFE based registration. SPIFFE is widely used for workload identity and could offer another path to a secure registration models without using namespaces. See #866

However, both options won't be a small change that could be done in the near future so we created enhancement requests to track them.