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?
Additional Context
No response
Feature Description
Currently, everything in the kcp build on top of the
rootworkspace. But this exposes some of the unnecessary details to the users. For example, if we usea structure like belowIf you are part of
org1, you might guessorg2structure. 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:
Which would follow closely the workspace API. But the idea is that one could request this "named
WorkspaceTreeobject and get its own tree assigned, which is not under the root.
Example:
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:department1or 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?
Additional Context
No response