In this blog post, we will understand what are the key features of the new software component part of SAP BTP Connectivity - SAP BTP transparent proxy. We will find out what it is valuable with and how it works.
Rapid software development is a vital asset for software companies. It helps them provide key features fast, lowering the cost, and giving a competitive advantage. To achieve this, developers need to be focused on developing new business functionality, putting minimal effort into technical aspects like connection establishment, authentication, and authorization. For that reason, we developed SAP BTP transparent proxy. It helps Kubernetes-based workloads to connect to on-premise and Internet systems easily and securely.
The SAP BTP transparent proxy lightens the way your Kubernetes-based workloads connect to Internet and on-premise systems, modelled as destination configurations. Let's look in more detail at how this is achieved.
The SAP BTP transparent proxy facilitates access to HTTP(s)-based systems by enriching your requests with credentials configured in your destination configuration. This feature enables you to consume target systems without the need of:
If you want to consume a system secured with OAuth, mTLS, or even Basic (not recommended, supported for the legacy use cases), you only need to reference a destination configuration of your choice inside your Kubernetes cluster, and voilà! The application developer doesn't have to implement all those complex parts, which is lowering the TCO, and saving you and your company time and money.
The SAP BTP connectivity proxy provides a SOCKS5 proxy authentication interface that you can use to access on-premise systems using TCP-based communication protocol securely. SOCKS5 is the industry standard for proxying TCP-based traffic. For security and multi-tenancy reasons, SAP BTP connectivity proxy supports two SOCKS5 authentication methods - user/password and a custom SAP BTP-specific authentication method based on OAuth. In short, the SOCKS5 authentication process consists of:
The SAP BTP transparent proxy facilitates and automates that process. This enables you to consume your on-premise system via a TCP-based communication protocol, without you having the need to perform the above-mentioned complex handshake and is especially helpful for scenarios where you need to connect to on-premise Mail or FTP servers, or databases, for which the available communication and protocol-specific client drivers do not support proxying via SOCKS5. All this happens behind the scenes and enables simple access to the target system. The only thing you do is to directly connect to the remote system - read more about this in the next section.
The SAP BTP transparent proxy creates and manages Kubernetes services inside your Kubernetes cluster for all remote systems you need access, for which destination configurations are managed centrally in the SAP Destination service. This makes the consumption of remote systems even easier, exposing an entry point toward the remote system inside your cluster. With this, there is no need of:
The SAP BTP transparent proxy is delivered as Docker images and a Helm chart which simplifies the installation. You could install it in your Kubernetes cluster, linking it to a Destination service instance, and optionally, SAP BTP connectivity proxy for on-premise connectivity.
The SAP BTP transparent proxy installation is located between your client application and the target system you want to connect to, intercepting the traffic and enriching your requests by providing proxy authorization, user principal propagation, etc. In the diagram above, you can see the connection flow and its direction from the starting point to the end system:
The SAP BTP transparent proxy is already released as generally available (GA). You can start using it following the Transparent Proxy for Kubernetes documentation.
In this blog post, we covered the key features of the SAP BTP transparent proxy and how developers benefit from it. I hope you like the seamless integration it provides. Ideas, suggestions, and comments are welcome.
Motivation
Rapid software development is a vital asset for software companies. It helps them provide key features fast, lowering the cost, and giving a competitive advantage. To achieve this, developers need to be focused on developing new business functionality, putting minimal effort into technical aspects like connection establishment, authentication, and authorization. For that reason, we developed SAP BTP transparent proxy. It helps Kubernetes-based workloads to connect to on-premise and Internet systems easily and securely.
Key Features
The SAP BTP transparent proxy lightens the way your Kubernetes-based workloads connect to Internet and on-premise systems, modelled as destination configurations. Let's look in more detail at how this is achieved.
Runtime automation of technical authentication
The SAP BTP transparent proxy facilitates access to HTTP(s)-based systems by enriching your requests with credentials configured in your destination configuration. This feature enables you to consume target systems without the need of:
- directly obtaining data from BTP Destination service about the target system
- dealing with technical authentication, including mutual Transport Layer Security (TLS)
If you want to consume a system secured with OAuth, mTLS, or even Basic (not recommended, supported for the legacy use cases), you only need to reference a destination configuration of your choice inside your Kubernetes cluster, and voilà! The application developer doesn't have to implement all those complex parts, which is lowering the TCO, and saving you and your company time and money.
Handshake with SAP BTP connectivity proxy
The SAP BTP connectivity proxy provides a SOCKS5 proxy authentication interface that you can use to access on-premise systems using TCP-based communication protocol securely. SOCKS5 is the industry standard for proxying TCP-based traffic. For security and multi-tenancy reasons, SAP BTP connectivity proxy supports two SOCKS5 authentication methods - user/password and a custom SAP BTP-specific authentication method based on OAuth. In short, the SOCKS5 authentication process consists of:
- Executing the initial request. The caller provides initial authentication data to negotiate the authentication method.
- Executing the authentication request. The caller negotiates the authentication sub-version and provides a JWT to authenticate.
- Optionally, the SAP BTP Cloud Connector location identifier can be sent to declare to which exact premise location you'd like the request to be routed to.
- Initial connection to be established to the target system.
The SAP BTP transparent proxy facilitates and automates that process. This enables you to consume your on-premise system via a TCP-based communication protocol, without you having the need to perform the above-mentioned complex handshake and is especially helpful for scenarios where you need to connect to on-premise Mail or FTP servers, or databases, for which the available communication and protocol-specific client drivers do not support proxying via SOCKS5. All this happens behind the scenes and enables simple access to the target system. The only thing you do is to directly connect to the remote system - read more about this in the next section.
Native access to remote systems from inside a Kubernetes cluster
The SAP BTP transparent proxy creates and manages Kubernetes services inside your Kubernetes cluster for all remote systems you need access, for which destination configurations are managed centrally in the SAP Destination service. This makes the consumption of remote systems even easier, exposing an entry point toward the remote system inside your cluster. With this, there is no need of:
- knowing the exact URL of a target system
- directly obtaining data from SAP Destination service about the target system
- if the target system is in your premise, dealing with the formal routing to SAP BTP connectivity proxy - both for native HTTP or generally for TCP-based communication protocols via SOCKS5
Installation and proxying
The SAP BTP transparent proxy is delivered as Docker images and a Helm chart which simplifies the installation. You could install it in your Kubernetes cluster, linking it to a Destination service instance, and optionally, SAP BTP connectivity proxy for on-premise connectivity.
Request flow diagram
The SAP BTP transparent proxy installation is located between your client application and the target system you want to connect to, intercepting the traffic and enriching your requests by providing proxy authorization, user principal propagation, etc. In the diagram above, you can see the connection flow and its direction from the starting point to the end system:
- For Internet-accessible systems, the SAP BTP transparent proxy routes the traffic directly to the remote system.
- For on-premise systems, the SAP BTP transparent proxy works in conjunction and complete harmony with the SAP BTP connectivity proxy, which serves as а cloud counterpart of the Cloud Connector, securely exposing the target on-premise systems.
Availability
The SAP BTP transparent proxy is already released as generally available (GA). You can start using it following the Transparent Proxy for Kubernetes documentation.
In this blog post, we covered the key features of the SAP BTP transparent proxy and how developers benefit from it. I hope you like the seamless integration it provides. Ideas, suggestions, and comments are welcome.
- SAP Managed Tags:
2 Comments
