Currently if you have only access to a namepsace on a shared Kubernetes cluster without cluster wide admin control you won't be able to:

- Create cluster wide RBAC ClusterRole or ClusterRoleBinding

- Create or get access to cluster-scoped resources (nodes, CRD)

- Use custom webhooks for example using sidecar injection

Many of the things that complex Kubernetes deployments are doing nowadays.

The point is that it's unsafe to allow tenants ClusterRole / admin on a shared cluster, but this is needed for many CRDs and Operators.

The Operator pattern is getting more and more popular, and most of then need ClusterRole.

As the service provider (internal team, or SaaS provider), this is a liability. The aim, from reading the README.md, is to provide the ability for each tenant to be ClusterRole / admin within their own cluster, hosted in a larger real cluster.

Jessie Frazelle has talked about this before, I'm not sure if this is the exact blog link, but it's related: Kubernetes in Kubernetes - https://blog.jessfraz.com/post/hard-multi-tenancy-in-kuberne...

(IMO) this isn't intended to be a product, it's an experiment in different ways to run Kubernetes workloads

k3s is on the way to becoming "production-ready", this appears to use k3s in the code. Perhaps it could be once it's proven out as something the community can use?

Possibly: testing and learning environments.

That was my question as well.