feature: provide access to different APIs of the same compute cluster

fgiloux commented 1 year ago

Feature Description

I would like to have two personas that need to sync resources to a compute cluster part of our service offering:

administrators that deploy infrastructure components: they will use resources as deployments.apps,services,ingresses.networking.k8s.io
end users that mainly need to create Tekton resources. They should not consume compute resources in other ways, i.e. deployments.

Both administrators and end users have their own workspaces, where they are allowed to bind the apiexport of the compute cluster.

Preventing end users to create deployments in their workspace could be addressed by quotas. This is however not ideal to expose an API in their workspace that they cannot leverage, to block them to use this API through a binding of an apiexport for their own compute.

Proposed Solution

Currently I am considering creating two SyncTargets in two separate workspaces (as the APIExport is always called kubernetes) and allow:

adminstrator to bind the one with deployments.apps,services,ingresses.networking.k8s.io
end users to bind the one with Tekton resources

Challenge: kcp sync command generate manifests where the following resources: deployments.apps", "secrets", "configmaps", "serviceaccounts are always synced. These manifests can be amended before they get applied to the compute cluster but:

is it future proof? The way resources to sync are specified may change
secrets and serviceaccounts are used to make possible for workload to talk to the kcp API (this is currently not a concern for us). In the first phase the Tekton controllers talk to the compute cluster API.

Alternative Solutions

Use quotas
Make possible to limit (through RBAC?) the resources that are available for binding to a SyncTarget: all resources deployment + Tekton get synced by the same syncer but administrators can "bind" all of them whereas end users only bind a subset.

Want to contribute?

[ ] I would like to work on this issue.

Additional Context

Discussion in this slack thread: https://kubernetes.slack.com/archives/C021U8WSAFK/p1663666920366639

sttts commented 1 year ago

kcp sync command generate manifests where the following resources: deployments.apps", "secrets", "configmaps", "serviceaccounts are always synced.

This definitely has to change. @qiujian16 has a PR up or even merged that makes the syncer automatically get the resources from the supported APIExport. I would guess with that merged, you should have a solution, shouldn't you?

Plus the topic about selective configmap/secret/serviceaccount syncing is necessary. With those two you should have Tekton-only syncing.

jmprusi commented 1 year ago

Plus the topic about selective configmap/secret/serviceaccount syncing is necessary. With those two you should have Tekton-only syncing.

There's an issue already about this topic: https://github.com/kcp-dev/contrib-tmc/issues/137

Roming22 commented 1 year ago

Is this feature still relevant, or is it made obsolete by kcp-dev/kcp#1895?

qiujian16 commented 1 year ago

I think it relates to PR https://github.com/kcp-dev/kcp/pull/2164

After it is merged. It could work like this:

You can have two workspaces location workspace: where synctarget resides, and administrator can access user workspace: where user can access

admin run the sync command kubectl kcp sync --apiexports root:compute|kubernetes, tekton-workspace|tekton-apiexport to start the syncer.
admin can create deployment in location workspace.
user creates tekton APIBinding in user workspace.
user creates a placement point to the location workspace.
user can create tekton resource in user workspace.

Does the above flow makes sense?

mjudeikis commented 7 months ago

/transfer-issue contrib-tmc

kcp-dev / contrib-tmc