feature: Implement WorkspaceTree for forest workspace hierarchy #3716

Feature Description

Currently, everything in the kcp build on top of the root workspace. But this exposes some of the unnecessary details to the users. For example, if we usea structure like below

root:
   organizations:
       org1
          departament1
          departament2
       org2
          departament1
          departament2
       org3

If you are part of org1, you might guess org2 structure. This is like saying "knowing your AWS account ID allows you to guess other people's account IDs," then doing some guesswork and trying to access resources.

kcp supports a forest-type structure, but it's not exposed.

Proposed Solution

Proposal is to add a new tenancy API object:

apiVersion: tenancy.kcp.io/v1alpha1
Kind: WorkspaceTree
spec:
   type:
   cluster:
status:
   ...

Which would follow closely the workspace API. But the idea is that one could request this "named WorkspaceTree
object and get its own tree assigned, which is not under the root.

Example:

root:
  organizations:
     {WorkspaceTree/foo, WorkspaceTree/bar}

foo:
  departament1
  departament2
bar:

Where foo, bar` could be user-provided, or randomly generated, making the system non-guessable. Use same base36 nomenclature.

And users would see this in their kubeconfig clusters/foo:department1 or random string.

This will include a reconciler that provides trees to form a forest.
Some arbitrary scheduling capabilities should be added to distributed workspaces.
If WorkspaceTree is deleted, all workspace tree should be purged. This should be guarded by finalisers
Advanced scheduling is out of scope.

Alternative Solutions

No response

Want to contribute?

• I would like to work on this issue.

Additional Context

No response