Feature: Create SA which enables Landscaper to apply CRs to the MCP itself

[In-Ko]

Understand the problem

When using the Landscaper for deployment of custom resources coming from an OCM Component, and those CRs need to be applied to the MCP itself, a dedicated SA is required with the proper authorisations to do that. Such an SA is currently not available, and therefore needs to be created manually, which can only be a workaround.

Context

For example: An OCM Component, with Landscaper extracting Crossplane resources out of that component + applying them to the MCP cluster.

Proposal Acceptance Criteria

• A proper SA is available, which can be used to apply the CRs to the MCP Cluster itself, so that other MCP Components like Crossplane Controllers or ESO can react on those CRs.

How much traction does this feature have?

This a much needed addition, as the overall Scenario of "OCM Component" + "Landscaper" + "Crossplane Resources" will get used more and more.

[sk31337]

I tried using:

apiVersion: landscaper.gardener.cloud/v1alpha1
kind: Target
metadata:
  name: local-mcp
  namespace: default
spec:
  type: landscaper.gardener.cloud/kubernetes-cluster
  config:
    selfConfig:
      expirationSeconds: 86400 # optional, defaults to 86400 = 60 * 60 * 24
      serviceAccount:
        name: landscaper-local-user
        namespace: default
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: landscaper-local-user
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: landscaper-local-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: openmcp:admin
subjects:
  - kind: ServiceAccount
    name: landscaper-local-user
    namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: landscaper-local-user-2
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name:  openmcp:admin:clusterscoped
subjects:
  - kind: ServiceAccount
    name: landscaper-local-user
    namespace: default

but I get the following error:

apiVersion: landscaper.gardener.cloud/v1alpha1
kind: DeployItem
[...]
status:
 lastError:
    codes:
    - ERR_TIMEOUT
    lastTransitionTime: "2025-09-04T15:48:20Z"
    lastUpdateTime: "2025-09-04T15:48:20Z"
    message: 'timeout at: "helm deployer: start reconcile"'
    operation: StandardTimeoutChecker.TimeoutExceeded
    reason: ProgressingTimeout
  lastErrors:
  - lastTransitionTime: "2025-09-04T15:33:18Z"
    lastUpdateTime: "2025-09-04T15:33:18Z"
    message: |2-

      Op: InstallHelmRelease - Reason: Install - Message: unable to install helm chart release: Unable to continue with install: could not get information about the resource ProviderConfig "provider-config-ref-name-btp-account" in namespace "": providerconfigs.btp.sap.crossplane.io "provider-config-ref-name-btp-account" is forbidden: User "system:serviceaccount:default:landscaper-local-user" cannot get resource "providerconfigs" in API group "btp.sap.crossplane.io" at the cluster scope
    operation: RealHelmDeployer.Deploy
    reason: installRelease

i don't get this error and everything works, when establishing a ClusterRoleBinding to cluster-admin

 ---
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
 metadata:
   name: landscaper-local-user
 roleRef:
   apiGroup: rbac.authorization.k8s.io
   kind: ClusterRole
   name: cluster-admin
 subjects:
   - kind: ServiceAccount
     name: landscaper-local-user
     namespace: default

[robertgraeff]

The providerconfigs.btp.sap.crossplane.io is a cluster-scoped resource. Therefore I think a RoleBinding does not suffice and a ClusterRoleBinding is needed.

[sk31337]

I can confirm, that the installation succeeds with:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: landscaper-local-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name:  openmcp:admin:clusterscoped
subjects:
  - kind: ServiceAccount
    name: landscaper-local-user
    namespace: default

[robertgraeff]

My concerns are:

• It depends on the scenario what the proper authorisations of the service account are. Providing a service account with cluster admin rights or some defined set of permissions would circumvent the mcp authorization concept.
• It is not clear in which namespace the service account should be provided. (We could create a controller that adds one to every namespace, except tha system namespace)

I would suggest that we stick to the mcp authorization concept.

• The user creates a service account on the mcp cluster in a namespace where it is needed (the namespace of the installation and self-target).
• The user adds the service account to the authorization section of the mcp object. In this way the mcp authorization concept is used, and we do introduce a second one in parallel.