feature: share instances of an API with other workspaces

[maleck13]

Feature Description

Some APIs and service are intended to be shared and can have different creators and consumers that may span multiple workspaces. An example of this would be a messaging system or a gateway. I would like to have a mechanism for sharing/ making an instance of an API visible (read only) with other workspaces where I have the permissions to do so.

Stories

I have provisioned a Gateway using Gateway API via a KCP workspace and placed a replica on each sync target within in a location. I want to share this Gateway object as a read only object into a set of other workspaces within my org that have access to this location so that they can create HTTPRoute objects and attach them to this Gateway. I don't want every workspace that wants to use HTTPRoutes to need to create their own Gateway.

I have provisioned a instance of a messaging service via a service API, there are multiple teams using multiple workspaces to develop applications that need to be able to see this service or features of this service (a topic for example) as available to them so that they can consume and publish messages without needing to create their own messaging service instance.

Proposed Solution

Currently I think a workspace admin could grant get/list access in their workspace to a resource to a group in another workspace via RBAC. This is not the most intuitive of options and requires the consumer to be told which workspace he has been granted permissions in.

Naively Ideally I think we want something like:

1. I express that this instance of an API object is available to a group
2. As a member of that group, I can list things that have been made available to me
3. As a member of that group and with correct RBAC I can then "bind" that thing into my workspace.

So similar to the APIExport concept but for API instance(s) rather than allowing new instances to be created

Alternative Solutions

No response

Want to contribute?

• I would like to work on this issue.

Additional Context

No response

[stevekuznetsov]

@sttts this sounds like another use-case for generic projection?

[maleck13]

yes there was some discussion on slack around this https://kubernetes.slack.com/archives/C021U8WSAFK/p1663229464646029

[sttts]

@stevekuznetsov no, projections cannot solve this. Projections are for all-or-nothing cases, i.e. to redirect a complete GVR to another service, a bit like aggregation in Kube, but hopefully without the operational implications on stability.

If we are talking about single objects, this must be about syncing in some way and some authorization mechanism to make those objects read-only. Anything else will horribly complicate the kubernetes storage stack, we cannot afford that.

So we could have a mechanism (some official API) ThingSharedObject(s) that drives a replication controller.