About Private Path services
Private Path services provide private connectivity for IBM Cloud and third-party services. A Private Path service requires a Private Path network load balancer to deploy a service on IBM Cloud and a Virtual Private Endpoint (VPE) gateway for consumers to connect to the service. Traffic stays on the IBM backbone without traversing the internet.
The typical process for creating private connectivity between Providers and Consumers is as follows:
- The provider creates a Private Path service.
- The provider associates their Private Path service with a Private Path NLB.
- The provider shares pertinent information with service consumers, including a unique Private Path service Cloud Resource Name (CRN).
- The consumer creates a VPE gateway that configures the Private Path service's CRN. In turn, a connection request is sent to the service Provider.
- The provider permits or denies the consumer's request and sets up an account policy, if need be (alternatively, the provider can set up an account policy to automatically permit or deny consumer requests).
- The consumer is notified of the status of the connection request. If permitted, the consumer can access the service; if denied, the consumer can contact the provider for further details.
For more information, see the Private Path solution guide.
Your ability to complete the following actions depends on the level of IAM permissions that are associated with your IBM Cloud account. For more information, see Required permissions.
Getting started with Private Path service
As a service provider, follow these steps to get started:
-
Make sure that you have a Virtual Private Cloud (VPC) and at least one subnet in the selected VPC.
-
Create a Private Path NLB.
- You can create a Private Path NLB when you create your Private Path service, or you can use the Load balancer for VPC provisioning page to create one. To create a Private Path load balancer separate from the Private Path service, see Creating a Private Path network load balancer.
- You must use the same account within the same VPC region for your Private Path NLB and Private Path service.
-
Create a Private Path service.
- Set the default policy for when an account doesn’t have a specific policy that is assigned to it. The default policy (Review) allows you to permit or deny each request, whereas Permit and Deny automate the process for connection requests without specific account policies.
- Create account policies for specific account IDs now or later. These policies determine what action to take when the provider receives a request from a specific account, and take precedence over the default policy.
Private Path service use cases
The following use cases show you the various ways you can use Private Path services.
Use case 1: Connecting a service to a single consumer
As a Provider, you want to connect your service to a Consumer without traffic traversing the internet and without giving access to your entire VPC. Your Consumer can be a customer, other division in your company, or something else.
Figure 1 illustrates how to establish a Private Path service. Establishing a Private Path service enables you to expose a service to a customer privately.
First, a Consumer's application connects to a VPE gateway in the Consumer's VPC. Then, the VPE gateway connects to the Private Path NLB in the Provider's VPC. In turn, the Private Path NLB connects to the Provider's service. The Provider's service then responds to the Consumer's request through Direct Server Return (DSR). This Private Path service activity is completely contained in a single region (US South) in an IBM Cloud private network.
Use case 2: Connecting a service to multiple consumers
Figure 2 illustrates how to establish a Private Path service with connections to multiple Consumers VPE gateways.
First, a Consumer's application connects to a VPE gateway in the Consumer's VPCs. Then, the VPE gateway connects to the Private Path NLB in the Provider's VPC. In turn, the Private Path NLB connects to the Provider's service. The Provider's service then responds to the Consumer's request through DSR. This Private Path service activity is completely contained in a single region (US South) in an IBM Cloud private network.
Use case 3: Connecting a service to a customer within your VPC
Figure 3 illustrates how to establish a Private Path service with connections to the VPE gateway of a Consumer within your VPC.
First, a Consumer's application connects to the Consumer's VPE gateway within the Provider's VPC. Then, the VPE gateway connects to the Private Path NLB in the Provider's VPC. In turn, the Private Path NLB connects to the Provider's service. The Provider's service then responds to the Consumer's request through DSR. This Private Path service activity is completely contained in a single region (US South) in an IBM Cloud private network.
Use case 4: Enabling an IBM Cloud service to connect to a customer's VPC
Private Path allows connection between an IBM Cloud service like IBM Cloud Code Engine and your VPC without compromising security or putting your VPC at risk. Code Engine is a multi-tenant compute service that runs source-code or containerized workloads. Its dynamic scaling capabilities allow your apps to automatically scale up and down, even to zero, based on incoming requests. With it’s pay-per-use model, Code Engine only charges for the compute capacity you actually use. For more information, see IBM Cloud Code Engine.
Figure 4 illustrates how to establish a Private Path service with connections to the VPE gateway of a Code Engine application and your VPC. First, the Code Engine application connects to the VPE gateway within the Code Engine's VPC. Then, the VPE gateway connects to the Private Path NLB in the Consumer's VPC. In turn, the Private Path NLB connects to the Consumer's application. The Consumer's application then responds to the request. This Private Path service activity is completely contained in a single region (US South) in an IBM Cloud private network.
