I’m still working on encrypting all network traffic between Connections and Component Pack servers. This time I checked the Ingress-Nginx Controller - TLS/HTTPS documentation.
The default configuration for connecting IHS with Component Pack uses the plain HTTP port 32080. All traffic like /social or the Tailored Experience wizard is routed from IHS to Kubernetes on port 32080.
Our target is to encrypt the traffic on port 32443.
Traffic Flow Process
- Client Connection: Client connects to HAProxy Load Balancer (port 443)
- HAProxy Routing: HAProxy has two forwarding rules:
- Rule 1: Forward HTTP/HTTPS traffic (443) to IBM HTTP Server
- Rule 2: Forward specific traffic to Kubernetes cluster (32443)
- IBM HTTP Server Processing: IBM HTTP Server processes requests and uses ProxyPass to forward back to HAProxy (port 32443)
- Kubernetes Routing: HAProxy forwards the ProxyPass traffic to Kubernetes NGINX Ingress (port 32443)
- Service Distribution: NGINX Ingress Controller routes requests to appropriate services and pods within the cluster
Port Configuration
- Client → HAProxy: 443 (HTTPS)
- HAProxy → IBM HTTP Server: 443
- IBM HTTP Server → HAProxy: 32443 (ProxyPass)
- HAProxy → Kubernetes: 32443
- NGINX Ingress: Receives on 32443, routes internally to services
Example Infrastructure Components
| Component | IP Address | Role |
|---|---|---|
| IBM HTTP Server | 10.0.22.90 | Front-end web server |
| HAProxy Load Balancer | 10.0.22.92 | Load balancing and forwarding |
| Kubernetes Cluster | 10.0.22.95 | Container orchestration with NGINX Ingress |
Create Certificate
First, we need to create a certificate for the ingress service. I used a self-signed certificate here, as it is not visible to our users, but you can also obtain an official one or request it from your company CA.
I created a certificate for the hostname cnx8-db2.stoeps.home and added the Kubernetes server as an alias. Additionally, I added the IP addresses of both servers.
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ingress.key -out ingress.cert -subj "/CN=cnx8-db2.stoeps.home/O=stoeps.home" -config <(cat <<EOF
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
CN = cnx8-db2.stoeps.home
O = stoeps.home
[v3_req]
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = cnx8-db2.stoeps.home
DNS.2 = cnx8-db2-cp.stoeps.home
IP.1 = 10.0.22.92
IP.2 = 10.0.22.95
email.1 = admin@stoeps.home
EOF
)
I added the Kubernetes hostname and IP address, as I want to test connections directly during troubleshooting. For basic functionality, the IP address and hostname of the load balancer are sufficient.
Add Certificate to Kubernetes Secret
Now upload the newly created certificate to a secret:
kubectl create secret tls ingress-secret --key ingress.key --cert ingress.cert -n connections
Edit Deployment for Ingress
The deployment cnx-ingress-ingress-nginx-controller needs an additional line to use the certificate (see line 14 in the next code block):
| |
To automate this step, use kubectl patch to add the line:
kubectl patch deployment cnx-ingress-ingress-nginx-controller \
-n connections \
--type='json' \
-p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--default-ssl-certificate=connections/ingress-secret"}]'
Restart All Deployments and StatefulSets
With up-to-date Kubernetes, we can restart with these two commands:
kubectl rollout restart sts -n connections
kubectl rollout restart deploy -n connections
Configure IBM HTTP Server (IHS)
Get the root certificate with openssl:
cd /opt/IBM/HTTPServer
openssl s_client -connect 10.0.22.95:32443 -servername 10.0.22.95 -showcerts < /dev/null 2>/dev/null | openssl x509 -outform PEM > server-cert.pem
Add ingress.cert as a trusted signer to the IHS keystore:
bin/gskcapicmd -cert -add -db cnx8-db2-was-key.kdb -pw password -label "ingress-root-cert" -file server-cert.pem
Edit /opt/IBM/HTTPServer/conf/httpd.conf:
cp conf/httpd.conf conf/httpd_conf.$(date +%F_%H%M%S)
# Change port to 32443
sed -i 's/32080/32443/g' conf/httpd.conf
# Change http to https in lines containing 32443
sed -i '/32443/s/http:/https:/g' conf/httpd.conf
Add ProxyPreserveHost On to httpd.conf (right after the entries ProxyPreserveHost On), then IHS will support TLS ProxyPass entries.
Restart HTTPServer: bin/apachectl -k graceful
On the Load Balancer (Optional)
Edit /etc/haproxy/haproxy.cfg
Copy the frontend cnx_ingress_http and backend masters_cnx_ingress_http, then replace 32080 with 32443 again.
The new sections will look like this:
frontend cnx_ingress_https
bind *:32443
mode tcp
option tcplog
timeout client 10800s
default_backend masters_cnx_ingress_https
backend masters_cnx_ingress_https
mode tcp
option tcplog
option tcp-check
balance roundrobin
default-server inter 10s downinter 5s rise 2 fall 2 slowstart 60s maxconn 1000 maxqueue 1024 weight 100
server cnx8-db2-cp.stoeps.home cnx8-db2-cp.stoeps.home:32443 check
Restart haproxy:
systemctl restart haproxy
Conclusion
With these configuration changes, we have successfully encrypted the network traffic between IBM HTTP Server and the Kubernetes NGINX Ingress Controller, moving from the unencrypted port 32080 to the secure port 32443. Combined with our previous work on Redis traffic encryption , we’ve significantly improved the security posture of our HCL Connections deployment.
The implementation covers the critical communication path where user data flows from the web server through the load balancer to the Kubernetes cluster. All ProxyPass traffic is now protected with TLS encryption, ensuring data confidentiality in transit.
The remaining component that still needs attention is Customizer, which presents its own unique challenges for traffic encryption. This will be the focus of future security enhancements as we work toward fully encrypted inter-service communication across the entire Connections infrastructure.
