How to Expose IBM FS Cloud Container App to Public

Are you looking for a way to expose your containerized applications to the internet without breaking compliance with IBM Cloud for Financial Services?

This guide walks through how to do just that. It shows how to securely expose your apps using the IBM Cloud Framework for Financial Services, with a focus on the IBM Cloud Private Path Service. This service helps you route external traffic to private clusters over secure, compliant VPC-to-VPC connections.

The Challenge

Organizations must control how information flows within and between systems, in accordance with defined security policies. To reduce misconfiguration risk and limit internet exposure, the IBM Cloud Framework for Financial Services recommends separating workloads and internet-facing components into distinct VPCs: a Workload VPC and an Edge VPC. You can find more on this structure in the IBM Cloud for Financial Services documentation.

This document outlines an approach to stack Public and Private Load Balancers without using a Transit Gateway. Instead, it takes advantage of VPE and Private Path with stable IPs to simplify the setup. This solution works for both internal workloads and third-party SaaS, and offers fine-grained control over traffic flow. It also supports clear separation of duties between the central network security team and individual application teams.

Solution Architectural Topology

The following diagram highlights the key building blocks of the architecture.

Key components:

• Cloud Internet Services
• Public Application Load balancer (ALB)
• Virtual Private Endpoint (VPE) for the Private Path Network Load Balancer (PPNLB)
• Private Path Network Load Balancer (PPNLB)
• OpenShift Cluster
  • Ingress Resources
  • Deployment PODs

By default, when you create a Load Balancer (LB) service in your cluster, an Application Load Balancer (ALB) for VPC is automatically provisioned outside the cluster, within your VPC. This ALB routes traffic to your application through private NodePorts that are opened on your worker nodes.

For enhanced security, IBM Cloud for Financial Services (FS Cloud) recommends using private clusters. That means the ALB should also be private. Creating a public Load Balancer directly in the workload VPC can weaken your security posture by bypassing key controls like separation of duties and Internet access verification. To maintain strong boundaries, FS Cloud recommends using a dedicated “Edge VPC” to host the network components that handle and filter Internet traffic.

VPE with Private Path helps on the Public and Private Load Balancer stacking.

Deploy Your Service in the Cluster

Obviously, the first step is to deploy your app in the cluster. Follow OpenShift application deployment instruction to deploy your service. In our example the deployed service name is echo-server. 

Create Service for Your App

The following example shows the yaml file to create the cluster service named echoserverservice for the application echo-server we created in earlier step.

apiVersion: v1
kind: Service
metadata:
  name: echoserverservice
spec:
  selector:
    app: echo-server
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080

Configure Ingress Resource

Create or modify an Ingress resource for your application. In the example below, it creates an Ingress for the service echoserverservice — this must match the name of your service deployed in the cluster. The host value should be the public domain mapped to your Public Load Balancer in the Edge VPC.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echoserveringressresource
spec:
  rules:
  - host: paris-ppnlb.ibm.eychenne.us
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: echoserverservice
            port:
              number: 8080

Create a Private Path Load Balancer

Use the OpenShift LoadBalancer service type with the private-path annotation to create a Private Path Network Load Balancer (PPNLB). Continuing with our echo-server example, here’s the YAML definition for the load balancer service:

apiVersion: v1
kind: Service
metadata:
  name: echo-vpc-nlb-eu-de-1
  namespace: openshift-ingress
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "private-path" # Required
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private" # Required
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "02b7-e4cb464c-b3a8-4f95-bb50-5e41c8f8a21a"
spec:
  type: LoadBalancer
  selector:
    ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
  ports:
   - name: http
     protocol: TCP
     port: 80
   - name: https
     protocol: TCP
     port: 443
  externalTrafficPolicy: Local # Specify Local or Cluster.

Make sure to include the private-path and subnet ID annotations in your LoadBalancer service definition. Also note that the Ingress resource listens on port 80 for HTTP and port 443 for HTTPS.

If the pools of the Private Path Network Load Balancer (PPNLB) aren’t showing as healthy, double-check the namespace used for the LoadBalancer service and verify the cluster security group settings.

Create Private Path Service

Now that the Private Path Network Load Balancer (PPNLB) is in place, the next step is to expose it via a Private Path Service.

Follow the IBM Cloud documentation to create a Private Path Service, and be sure to select the PPNLB you created earlier (in our example, this is my_load_balancer).

This step completes the configuration in the workload VPC. Once set up, the Private Path Service makes your backend service (in this case, echo-server) accessible over the private IBM Cloud network from any VPC in the same region.

To consume this service from another VPC (such as the Edge VPC), you’ll need to create a Virtual Private Endpoint (VPE), which we’ll cover next.

Create Virtual Private Endpoint

A VPE allows you to privately access the Private Path Service from a VPC in the same region. The VPC where the VPE is created can be in a different account from where the Private Path Service resides.

For this example, the VPC accessing the service is referred to as the Edge VPC.

To set up the VPE:

1. Follow IBM’s documentation for creating a Virtual Private Endpoint.
2. Be sure to use the CRN of the Private Path Service you created earlier.
3. If the Private Path Service is set to “review all requests,” you’ll need to approve the connection request before private connectivity is established.

Create Public ALB

IBM Cloud supports both public and private-facing Application Load Balancers (ALBs) with SSL offloading capabilities. These ALBs support both Layer 7 (HTTP/HTTPS) and Layer 4 (TCP) load balancing.

To create a public ALB, follow the IBM Cloud documentation. Be sure to specify that the ALB should be public-facing.

The key part of this setup is adding the Virtual Private Endpoint (VPE) as a member of the ALB’s backend pool.

Adding the VPE to the Backend Pool

When attaching the VPE to the pool:

• Choose the “Other devices” option.
• Manually enter the IP address and port of the VPE.
• If your VPE has three Reserved IPs, enter all three IP/port combinations as separate pool members.

The example below shows how to enter the IP and port values when configuring the pool.

Make sure to create a frontend listener for the ALB (typically on port 80 for HTTP or 443 for HTTPS) and set the backend pool you created earlier as the default pool.

That’s it! Your setup is complete.

Your application is now securely accessible via the Public and Private Load Balancer stack.

As an optional step, you can add a CNAME record in your DNS to map a custom domain to the ALB’s fully qualified domain name (FQDN).