feature: Manage workspaces

[MisterMX]

Feature Description

kcp-operator should provide a CR to manage kcp workspaces through the host cluster.

kcp-operator already provides APIs to manage shards, proxies and kubeconfigs. But for a complete kcp installation it also requires workspaces to be configured and made available to users.

Proposed Solution

Since workspaces are also just objects inside their parent workspaces, a generic "object" API can achieve this:

---
apiVersion: operator.kcp.io/v1alpha1
kind: WorkspaceObject
metadata:
  name: object.workspace.custom
  namespace: kcp
spec:
  rootShard:
    ref:
      name: shard-sample
  workspace:
    path: root:custom-parent
  managementPolicies: # configure which CRUD operations to perform
    - Create
    - Update
    - Delete
  manifest: # creates a workspace :root:custom-parent:test
    apiVersion: tenancy.kcp.io/v1alpha1
    kind: Workspace
    metadata:
      name: test
    spec: {}

Furthermore, a generic API also has the following benefits:

• decoupling kcp-operator and kcp APIs. kcp-operator does not necessarily need to be updated to work with kcp APIs as it is using dynamic client
• manage any kind of object, not just workspaces
• easy and transparent setup by just referencing the root shard and naming the path to the target workspace

Alternative Solutions

Alternative 1: Dedicated, strongly typed Workspace and possible more APIs to manage kcp objects

A dedicated API has the benefit of integrated 1st level schema validation but also has the downside the operator API is tightly coupled to KCP. For every change in the kcp API it requires an update in the kcp-operator.

Alternative 2: Use external solutions like Crossplane provider-kubernetes

Instead of implementing an API in the kcp-operator, an external solution like github.com/crossplane-contrib/provider-kubernetes could be used to connect to a workspace (like a standard k8s cluster) and manage the objects through that.

However, the downside is that (1) it is not as well integrated into kcp and (2) does not use the kcp-operator types like shard references and workspace paths to establish a connection internally. For example for provider-kubernetes in crossplane, it requires a Crossplane installation, a secret with a kubeconfig, a providerconfig and an external object. With an implementation in kcp-operator it only requires one additional kind and a reference to the root shard (see proposed solution).

Want to contribute?

• I would like to work on this issue.

Additional Context

No response