Skip to main content
SAP Pentest Playbook
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  2. /
  3. SAP Business Technology Platform
  4. /
  5. Known Attack Vectors
  6. /
  7. Kyma (Kubernetes) General
  8. /
  9. Kyma Application Connector Pivot
Edit page

Kyma Application Connector Pivot

Description

Kyma’s Application Connector registers secured on-premise APIs and reaches them via SAP Cloud Connector, storing the connection credentials as Kubernetes Secrets in kyma-system. This is the Kyma equivalent of the Cloud Foundry Destination/Connectivity chain: a single-namespace secret read turns into an authenticated tunnel into the customer’s on-premise SAP landscape. This page assumes a foothold with get/list on secrets in kyma-system or the ability to reach the Connectivity Proxy service - see the Kyma overview for establishing it.

Risk

kyma-system co-hosts the Application Connector’s on-prem credentials alongside the BTP Operator’s Service Manager credentials, so one get secrets -n kyma-system grant simultaneously gates an on-premise ERP/S4 pivot and (via BTP Operator escape) subaccount-wide platform-API control. A workload that can merely reach the Connectivity Proxy inherits the configured on-prem access without reading any Secret at all.

Options

Read the stored on-prem credentials

Application Connector registers secured on-premise APIs (Basic Auth, OAuth client id/secret, OAuth 2.0 mTLS, or direct client certs) reached via SAP Cloud Connector, and all four credential types are stored as Kubernetes Secrets in kyma-system. Any principal with get/list on secrets in kyma-system - a common over-grant for “cluster admin” or “developer” roles - can read these and obtain a direct, authenticated tunnel into the customer’s on-premise SAP landscape.

kubectl get secrets -n kyma-system -o yaml | grep -A5 -i "application-connector\|basic-auth\|oauth"

Ride the Connectivity Proxy without the Secrets

The Connectivity Proxy itself sets up the bidirectional tunnel from Kyma to on-prem via Cloud Connector, proxying HTTP, RFC, LDAP, and SOCKS5 - all four enabled by default. A workload that can simply reach the Connectivity Proxy service in-cluster inherits whatever on-prem access is configured, without needing the Secrets directly. CSRF protection on registered APIs is opt-in (csrfInfo.tokenEndpointURL), not automatic - worth checking per registered API.

The realistic attack against the on-prem boundary from Kyma is therefore credential-/reachability-based, not network-scanning based - the same conclusion as the Cloud Foundry side. Cross-reference the generic Cloud Connector attack surface rather than duplicating it here - see SAP Cloud Connector.

Mitigation

  • Treat get/list on secrets in kyma-system as the single highest-value RBAC grant in the cluster - restrict it to a minimal admin set.
  • Prefer certificate/mTLS-based Application Connector auth over Basic Auth/OAuth client-secret where supported.
  • Enable CSRF protection (csrfInfo.tokenEndpointURL) on every registered API.
  • Restrict which workloads can reach the Connectivity Proxy service in-cluster (NetworkPolicy), since reachability alone confers on-prem access.
  • Constrain Cloud Connector application-level whitelisting to the minimum necessary hosts/ports on the on-prem side.

Detection and Monitoring

  • Kubernetes audit logs for get/list on secrets in kyma-system from ServiceAccounts outside the platform-operator set.
  • Connectivity Proxy access logs for tunnel usage from unexpected in-cluster workloads.
  • Cloud Connector audit logs - note the SCC default audit level does not record successful accesses; raise it on sensitive backends (see BTP Audit Log Blind Spots).

References