Epic: PlatformService for resource copying

Description

We have several ServiceProviders and also at least one PlatformService that require secrets to be copied around.

Let's take the new platform service helm as an example: This is an internal platform service (part of the openmcp operator) which can deploy arbitrary helm charts onto clusters via flux, by creating HelmRelease resources for it. There are two situations in which copying a secret is required:

• If the registry containing the helm chart requires authentication, its credentials need to be in a secret which is next to the HelmRelease resource, which again is next to the Cluster it belongs to (on the platform cluster).
• If the chart itself references secrets, e.g. image pull secrets, they have to be put into the designated namespace on the target cluster.

While each platform service / service provider could implement its own secret copying mechanism or rely on a shared library, some of these secrets might get rotated, which would require each of these controllers to watch secrets. This increases not only complexity, but also load on the k8s apiserver. A better solution would therefore be to have an explicit controller that handles all secret copying. This would reduce the code required to copy secrets in each individual platform service / service provider to just creating the necessary CRs for the secret copying controller.

Goal

Create a Platform Service that can sync resources like Secrets and ConfigMaps from one place to another. From one namespace to another namespace in the same cluster, and from one cluster to another cluster.
Other types for resources might follow. Let's focus on Secrets and ConfigMaps with this epic

Acceptance Criteria

• Platform Service is based on https://github.com/openmcp-project/platform-service-template
  • We decided to use the platform service as a test for the multicluster-runtime. Since this requires significant changes to code which can usually be taken from the template unmodified, this would have been a bad scenario for testing the template. We therefore decided to drop this requirement.
• Developing the Platform Service along the developer guide
  • We dropped this due to the multicluster-runtime experiment, see above.
• Gather requirements from all currently known secret copying scenarios to ensure that the new platform service can handle all of our use-cases. This is basically "what should the controller's CR look like?".
• Platform Service can handle Secret, (Kyverno) Policies syncing and ConfigMap syncing
• Unit Tests
• Developer/Operator Documentation
• Platform Services presented in Community Call
• Create new issues for all controllers which currently implement their own secret copying. The goal of the task should be to switch to using the new platform service or to give a reason why this does not make sense.

Links to existing resources

• https://github.com/openmcp-project/platform-service-template
• Platform Service Development Guide
• https://github.com/kbind-dev/kbind

Out of Scope

• Migrate Secret Copying mechanism in existing Service Providers to Platform Services (create follow-up epic)