TIBCO Platform and capability deployments with Istio Ingress Gateway
1. Summary
TIBCO Platform and capability deployments with Istio Ingress Gateway

1. Summary
This document outlines testing conducted for using the Istio Ingress Gateway with TIBCO Dataplane. This document is created as the Istio Ingress Gateway is not supported as of TIBCO Platform Control Plane version 1.13 version.
This guide is intended for users who wish to deploy TIBCO Platform and its capabilities (e.g., BW6/BWCE and Flogo), along with their applications, using the Istio Ingress Gateway. It provides the necessary configuration steps.
Important Note: Users must manually create the required Istio Gateway and VirtualService objects to enable this functionality. When TIBCO officially supports an ingress solution, the TIBCO Platform automatically handles the creation of the necessary ingress objects; however, this automatic object creation does not occur with the Istio Ingress Gateway setup described here.
2. Prerequisites & Naming Conventions
Infrastructure used to create this document
- TIBCO Platform 1.13
- Kubernetes Cluster: v1.33+ (I have used GKE for testing, however this should work for AKS, EKS, minikube also)
- Istio: v1.28.0+ (Ingress Gateway in istio-system) Istio / Ingress Gateways
- Cert-Manager: (Optional) for TLS/HTTPS needed for secret holding tls crt and key
- Domain: bwcegke.example.com which you can register in the dns zone. Note that, same domain will be used by all the BWCE Applications. If you have Flogo, it is better to have another flogogke.example.com domain pointing to the LB of the istio ingress gateway. And there also you can use the same pattern described in this document.
Component Identifiers
Use these values as references. Replace specific IDs with your actual environment data.

3. Architecture Overview
We use a Shared Gateway pattern. A single Istio Gateway listener handles traffic for the domain bwcegke.example.com. VirtualServices are then used to “split” traffic based on the URL path. It is recommended to have a separate Gateway listener per capability which then should be shared by application types (BWCE or Flogo) using Virtual Services per application.
- Shared Gateway: Terminates TLS (HTTPS) for bwcegke.example.com.
- Provisioner VirtualService: Routes management traffic (/tibco/bw/…) to the Provisioner.
- Application VirtualService: Routes app traffic (/tibco/apps/…) to specific BWCE services.
4. Step 1: Infrastructure Setup (Deploy Once)
This section sets up the shared entry point and the management console routing. You generally apply this once per cluster/environment.
File: 01-infrastructure-setup.yaml
YAML
# ---------------------------------------------------------
# 1. SHARED GATEWAY (The Entry Point)
# Do NOT create other Gateways for this host/port or for BWCE Apps
# ---------------------------------------------------------
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: bwprovisioner-gateway
namespace: dp-gke
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "bwcegke.example.com"
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: bwcegke-tls # Must exist in istio-system
hosts:
- "bwcegke.example.com"
---
# ---------------------------------------------------------
# 2. PROVISIONER VIRTUAL SERVICE (Management Console)
# Routes traffic to the TIBCO Provisioner Service
# ---------------------------------------------------------
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: bwprovisioner-vs
namespace: dp-gke
spec:
hosts:
- "bwcegke.example.com"
gateways:
- bwprovisioner-gateway # ATTACH TO SHARED GATEWAY
http:
- match:
- uri:
prefix: "/tibco/bw/d4o61daal6jc73d7ubmg/"
rewrite:
uriRegexRewrite:
match: "/tibco/bw/d4o61daal6jc73d7ubmg(/|$)(.*)"
rewrite: "/\\2"
headers:
request:
set:
# Headers required for the Provisioner to know its public URL
X-Forwarded-Prefix: "/tibco/bw/d4o61daal6jc73d7ubmg"
X-Forwarded-Proto: "https"
X-Forwarded-Host: "bwcegke.example.com"
X-Forwarded-Port: "443"
X-Forwarded-For: "%DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%"
route:
- destination:
host: bwprovisioner
port:
number: 7816
Apply it:
kubectl apply -f 01-infrastructure-setup.yaml
5. Step 2: Application Deployment (Per App)
For every new application you deploy, create a dedicated VirtualService using this template.
File: 02-app-template.yaml
Replace:
- {APP_NAME_VS} -> e.g., order-processing-vs
- {APP_ID} -> e.g., abc123def456
- {SERVICE_NAME} -> e.g., com-tibco-tp-order-processing
YAML
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: {APP_NAME_VS}
namespace: dp-gke
spec:
hosts:
- "bwcegke.example.com"
gateways:
- bwprovisioner-gateway # ALWAYS use the shared gateway
http:
- match:
- uri:
prefix: "/tibco/apps/{APP_ID}/Resource"
rewrite:
uriRegexRewrite:
match: "/tibco/apps/{APP_ID}/Resource(/|$)(.*)"
rewrite: "/\\2"
headers:
request:
set:
# Critical for Swagger UI and internal links
X-Forwarded-Prefix: "/tibco/apps/{APP_ID}/Resource"
X-Forwarded-Proto: "https"
X-Forwarded-Host: "bwcegke.example.com"
X-Forwarded-Port: "443"
X-Forwarded-For: "%DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%"
route:
- destination:
host: {SERVICE_NAME}
port:
number: 8080
Appendix I: Verification & Testing
1. Verify Provisioner (Management)
Check if the management console is reachable via the rewritten path.
curl -I -k https://bwcegke.example.com/tibco/bw/d4o61daal6jc73d7ubmg/health
Expected: HTTP 200 OK
2. Verify Application (Workload)
Check if your specific application is reachable and if the Swagger UI loads.
curl -I -k https://bwcegke.example.com/tibco/apps/{APP_ID}/Resource/swagger/swagger.json
Expected: HTTP 200 OK
Appendix II: Troubleshooting Common Issues
Issue 1: 404 Not Found (External)
- Cause: You likely created a duplicate gateway (e.g., my-app-gateway) listening on the same host (bwcegke.example.com).
- Fix:
- kubectl get gateway -n dp-gke
- Delete any gateway other than bwprovisioner-gateway.
- Update your App’s VirtualService to reference bwprovisioner-gateway.
Issue 2: Swagger UI Links are Broken
- Cause: The application doesn’t know it is behind a reverse proxy (Istio) and is generating links using http://internal-ip:8080.
- Fix: Ensure the headers section (X-Forwarded-Prefix, X-Forwarded-Host, X-Forwarded-Proto) is present in your VirtualService configuration as shown in Step 4.
메타데이터
- post_id
- 2dd17fbabbb3
- slug
- tibco-platform-and-capability-deployments-with-istio-ingress-gateway-2dd17fbabbb3
- url
- https://medium.com/@kulbhushan.bhalerao/tibco-platform-and-capability-deployments-with-istio-ingress-gateway-2dd17fbabbb3
- canonical_url
- https://medium.com/@kulbhushan.bhalerao/tibco-platform-and-capability-deployments-with-istio-ingress-gateway-2dd17fbabbb3
- author_url
- https://medium.com/@kulbhushan.bhalerao
- status
- ok
- fetched_at
- 2026-08-08 03:53:51