serviceExposures Only Generated for Service-Only Charts

[xyunxylona]

Upstream code:

• Non-configurable template: https://github.com/cap-js/cap-operator-plugin/blob/v0.14.0/lib/util.js#L619-L626 - gated by if (isService)
• Configurable template: https://github.com/cap-js/cap-operator-plugin/blob/v0.14.0/lib/util.js#L522-L533 - same if (isService) guard
• Service-only check: https://github.com/cap-js/cap-operator-plugin/blob/v0.14.0/lib/util.js#L77-L83 - reads app.kubernetes.io/component: service-only from Chart.yaml

Problem:
The serviceExposures Helm block is only generated when the chart has app.kubernetes.io/component: service-only. Multi-tenant CAP apps with approuters cannot configure direct ingress routes.

This matters because traffic through the approuter loses the XFCC header due to Istio proxy sanitization. Multi-tenant apps need serviceExposures to route BTP callbacks (e.g., /-/cds/saas-provisioning/...) directly to the backend service, bypassing the approuter so the original client certificate is preserved.

Expected behavior:
Generate the serviceExposures block unconditionally for all chart types. It's already wrapped in {{- if .Values.serviceExposures }}, so it has no effect when not configured. There's no reason to restrict it to service-only charts.

Severity:
Medium - blocks a valid and common use case for multi-tenant apps.

[Pavan-SAP]

Hi Aaron,
As mentioned in your other issue. The call for provisioning is handled within the CAP Operator Server itself,

Be default (also for security), we do not expose the backend workloads and only the router is exposed by default.

You can always create a template based chart to override this behaviour. In most production scenarios a template based helm chart would make sense. Any serviceExposues you add to your runtime values would then be used by the chart accordingly.

Closing this as invalid as the provisioning call is meant to be forwarded to the Server of CAP Operator and not to app backend.

Regards,
Pavan

[xyunxylona]

@Pavan-SAP Thanks for the quick response. I think there may be a misunderstanding about the use case here, so let me clarify.

You're right that the CAP Operator Subscription Server handles tenant subscription callbacks (the PUT/DELETE on /-/cds/saas-provisioning/tenant/{id}). But the dependencies callback is a different endpoint. SaaS Registry calls GET /-/cds/saas-provisioning/dependencies on the application backend (served by cds-mtxs), not on the CAP Operator Server. This call needs to reach the app workload directly.

Here's the concrete problem:

1. SaaS Registry calls the dependencies endpoint on the app
2. Traffic enters through the ingress gateway and hits the approuter
3. The approuter forwards the request to the mtx-sidecar
4. During that pod-to-pod hop, Istio's Envoy sidecar replaces the original XFCC header with mesh certificate info (SANITIZE_SET mode)
5. cds-mtxs rejects the request with 401 Invalid certificate

serviceExposures is the CAP Operator's own solution for this: it creates a VirtualService that routes ingress traffic directly to the target workload, bypassing the approuter and preserving the XFCC header. This feature already works at runtime for any CAPApplicationVersion, regardless of chart type.

The only gap is in the plugin's template generation. The serviceExposures block is gated behind isService in the plugin code, so non-service-only charts never get the Helm conditional, even though:

• The CRD supports it for all chart types
• The generated template already uses {{- if .Values.serviceExposures }}, so it's a no-op when unconfigured
• There's no security downside since users must explicitly populate the values

cc: @anirudhprasad-sap

[Pavan-SAP]

Hi @xyunxylona ,
I see. However as the default behaviour we recommend is to use approuter for getDependencies - the XFCC header approach does work there (approuter automatically handles getDependencies).
Is there a specific reason why you want to use the cap mtxs based one?

But I see the issue with serviceExposure that we will fix regardless.

BTW, we plan to also to implement the getDepenencies in the CAP Operator, which we would recommend as the option to use for most cases going forward. As this makes most sense and apps don't need to maintain any unnecessary exposed workloads (cds-mtxs) or additional configurations (annotations).

[anirudhprasad-sap]

serviceExposure restriction removed in version https://github.com/cap-js/cap-operator-plugin/releases/tag/v0.15.0

[xyunxylona]

Thanks @anirudhprasad-sap for the quick fix.

BTW, we plan to also to implement the getDepenencies in the CAP Operator, which we would recommend as the option to use for most cases going forward. As this makes most sense and apps don't need to maintain any unnecessary exposed workloads (cds-mtxs) or additional configurations (annotations).

Can you let me know when the above is done?

[anirudhprasad-sap]

Can you let me know when the above is done?

@xyunxylona Yes, we will let you know once it is available.