0002: Add mounts proposal

[mjudeikis]

Proposal for Mounts API

[kcp-ci-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign davidfestal for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mjudeikis]

We have 2 areas where this might be implemented, and I don't quite like it.

• For URL its easy - index/proxy just routes them where it need to go (direct or via external VW)
• For cherry-picked GVR - potentially index/proxy too as I could see this being needed/nice feature to have in proxy as such overall
• SoftLink/Other workspace with redirect - its challenging. Currently our client tooling is based on assumption that ws use always follows hierarchy/relative or absolute paths. Now lets say I have following:

➜  kcp git:(35584e0b) ✗ k ws use ~
➜  kcp git:(35584e0b) ✗ k get logicalcluster
NAME      PHASE   URL                                                AGE
cluster   Ready   https://192.168.1.105:6443/clusters/kvdk2spgmbix   38m
➜  kcp git:(35584e0b) ✗ k get ws
NAME     TYPE        REGION   PHASE   URL                                              AGE
root-4   universal            Ready   https://192.168.1.105:6443/clusters/root:1:2:3   28m 

root-4 is manually created workspace in home workspace. By executing ws use root-4 it will NOT take into account url of the workspace, but would just create path kvdk2spgmbix:root-4 which is wrong.

I somehow think that we could do this with mounts too where users would still need to create workspace, but mount something ontop. This way we could route traffic to it via index. But there is caviate - there is no redirect as such as now root-4 is just serving root:1:2:3 content at api layer.

So to make it really redirect - we need would need to instruct client tooling to know that is just just override url in kubeconfig, over using name to construct the path. Which makes it client-side implementation, and I don't like it.

I would like to keep handing of different mounts at the proxy layer. Maybe try 301 response to kubectl and force somehow plugin to handle change? Or something under these lines...

@sttts, @embik any ideas?

[embik]

Additional comment that doesn't match any section right now: Can we describe how authN/authZ works in this? I understand that the backend is out of scope, but what kind of data is kcp sending to the proxy backend? Is the backend responsible for resolving authN/authZ?

[mjudeikis]

TODO: Summarise this here too https://kubernetes.slack.com/archives/C021U8WSAFK/p1712597717851069

[mjudeikis]

Additional comment that doesn't match any section right now: Can we describe how authN/authZ works in this? I understand that the backend is out of scope, but what kind of data is kcp sending to the proxy backend? Is the backend responsible for resolving authN/authZ?

Will add this as non-goal as this is the responsibility of implementers to arrange this either by federating identities or other means