Establish Trust Onboarding API <-> Provider from `ManagedControlPlane`

[GenosseOtt]

Description
As a platform admin I want to bring the new Onboarding API Provider to my umbrella ManagedControlPlane
When Crossplane Provider Onbaording API is enabled in an MCP, we want to automate its trust to the Onboarding API so that end users can order additional MCPs/WS/etc right away.

End user specifies provider in ManagedControlPlane

apiVersion: core.openmcp.cloud/v1alpha1
kind: ManagedControlPlane
metadata:
  name: yo-mcp
spec:
...
  components:
...
    crossplane:
      version: 1.18.0
      providers:
        - name: onboarding-api
          version: 1.0.0

End user creates a GitHub Service Issue with following info:

• a
  (@reshnm )

Technical steps

• Provider authenticates via ServiceAcocunt
• Provider creates Token, rotates regularly automated, with right audience

Next Steps

• Enable trust from MCP to Onboarding API
• v1: Partly manual process (Useres reach out via Github Support issue, process described in manual process)

Out of scope

• Automated trust enablement

Done Criteria

• End users can activate provider and Trust between MCP and Onboarding API is accomplished on their behalf
• Provider is visible in CRD browser and release channel
• End user guide exists
• Stretch: Provider can be activated in managed control plane

[GenosseOtt]

@reshnm & @gergely-szabo-sap lets follow up on the next steps :-)

[reshnm]

First, we could have a manual approach with setting up the required objects on the ManagedControlPlane and the onboarding cluster manually. It would be good to have an operations guide that contains the necessary steps.

An automated step would need to have an additional controller in the mcp-operator.
A project has to be annotated to set up the trust relation between the onboarding cluster and the ManagedControlPlane

apiVersion: core.openmcp.cloud/v1alpha1
kind: Project
metadata:
  name: test
  annotations:
    openmcp.cloud/trust-mcp: "<project-name>--<workspace-name>--<mcp-name>"

When the responsible controller detects a project with this annotation, it looks up the .status.components.apiServer.serverAccountIssuer url and creates a Gardener OpenIDConnect resource on the onboarding cluster which established the trust.

In the next step, the user has to authorize the ManagedControlPlane on projects and workspaces:

apiVersion: core.openmcp.cloud/v1alpha1
kind: Workspace
metadata:
  name: dev
  namespace: project-test
spec:
  members:
    - kind: User
      name: mcp--<project-name>--<workspace-name>--<mcp-name>:system:serviceaccount:<sa-namespace-on-mcp>:<sa-name-on-mcp>
      roles:
        - admin

@ValentinGerlach do you have any input on this? Does this make sense?

[ValentinGerlach]

In my opinion it would make more sense to have a label or annotation on the ManagedControlPlane resource. OpenIDConnect resources are cluster-scoped so they are not really related to the project.

The user can then add the ManagedControlPlane as a member to a Project or Workspace either as a kind: User (for any MCP service account) or using a special kind: ManagedControlPlane (for convenient use of the Onboarding Crossplane Provider).

apiVersion: core.openmcp.cloud/v1alpha1
kind: Workspace
metadata:
  name: dev
  namespace: project-test
spec:
  members:
    - kind: ManagedControlPlane
      name: my-mcp
      namespace: project-other--ws-umbrella
      roles:
        - admin

The controller responsible for project/workspaces would translate this to a RBAC subject for the crossplane-provider-onboarding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: example
  namespace: project-test--ws-dev
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: mcp:<uid>:system:serviceaccount:crossplane-system:provider-onboarding

Using the MCP's .metadata.uid instead of the name prevents that an MCP accidentally gains access to resources when it is deleted and recreated with the same name. Gardener also includes the UID in the Service Account Issuer URL.

[gergely-szabo-sap]

I've created a demo draft of the current version. This is a verified step-by-step demo description. The steps that need to be automated are these:

• Deploy a missing ClusterRole
• Create the OpenIDConnect for MCP

Please advise, how to proceed with this task.

[ValentinGerlach]

I think this ticket is not refineable yet. There are a few things that need to be done first:

• Publish the onboarding provider to github.com
• The onboarding provider needs to be able to do a SelfSubjectReview to find out its own username on the onboarding cluster
• SAP internal: The onboarding provider needs to become a part of the release channel to receive a stable, predictable service account name

[gergely-szabo-sap]

* The onboarding provider needs to be able to do a [SelfSubjectReview](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/self-subject-review-v1/) to find out its own username on the onboarding cluster

If I get it right, this step would eliminate the need to specify the SA parameters in the ProviderConfig, such as name and namespace.

@reshnm had a counterargument regarding this. He argued that the SA used for trust establishment shall be separated from the provider SA.

I might be on the wrong track here, so please advise.

[reshnm]

My argument was that the onboarding provider should not use its own user respective its own service account.
The provider should rather allow to specify a user service account for which a token is created which is then used for accessing the crate cluster.

This, in my opinion, has several advantages:

• We don't need to guess the service account of the provider or make it stable
• Users of the onboarding provider can use multiple identities for managing objects on the onboarding api

I was thinking that the service account that is being used has to be in the same namespace as the provider config. Unfortunately the providerconfig is cluster scoped. Therefore this is not working.
This means a user could use just any namespace on the MCP.
But going forward to architecture V2 I think this is no longer a problem.

@ValentinGerlach please provide feedback on my thoughts.