How can I manage HTTPS certificates with Kubernetes Ingress and Traffic Parrot?

Kubernetes Ingress is often used to expose HTTPS services outside the cluster. There are several options available for managing HTTPS certificates, which are described below.

Option A - Certificates only in Ingress

• Use TP HTTP for both HTTP and HTTPS use cases
• Ingress manages all HTTPS certificates
• Ingress does all TLS offloading
• Ingress can have different HTTPS certificates per hostname
• TP only receives HTTP requests never HTTPS

Option B - Certificates only in TP

• Use TP HTTP for HTTP use cases
• Use TP HTTPS for HTTPS use cases
• Ingress passes through HTTPS connections to TP HTTPS backend using SNI TLS proxy via SNI hostname
• TP manages all HTTPS certificates
• TP receives HTTPS requests
• TP does all TLS offloading
• Requires compatible HTTPS clients that support client SNI (e.g. not supported in Java 6)
• Ingress performance overhead incurred due to ingress SNI TLS proxy

Option C - Certificates in both Ingress and TP

• Use TP HTTP for HTTP use cases
• Use TP HTTPS for HTTPS use cases
• Ingress does TLS offloading for original request from the client
• Ingress has a copy of the certificates used by the client
• Ingress initiates new HTTPS connection to TP HTTPS backend with client certificates
• TP receives HTTPS requests
• TP does TLS offloading for the request from the ingress controller
• Ingress performance overhead incurred due to initiating new connection with client certificates
• Maintenance overhead incurred, end users now need to provide the client certificates too

Summary

If the same HTTPS certificates are used globally then Option A is the simplest.

If certificates are per virtual service then Option B is preferable over Option C, unless you are using HTTPS clients that do not support SNI, in which case Option C could be used instead.

You may prefer Option A over both Option B and C for certificates per virtual service if you would like HTTPS to be managed fully by Ingress instead of TP. Option A is the simplest infrastructure but means there are two configuration points: TP for the HTTP virtual service configuration and Ingress for the HTTPS certificate configuration.

How can I expose Traffic Parrot virtual services outside my Kubernetes cluster?

When hosting Traffic Parrot virtual services in a Kubernetes cluster, sometimes access to the virtual services is required from traffic outside of the Kubernetes cluster. In these cases, it is typical to use Kubernetes Ingress alongside a DNS name server to provide access to the services inside the cluster. Here are two common options used to achieve this.

Option A - Static domain with unique Ingress path mappings

• DNS server points static domain record to static Ingress controller IP
• Unique paths are used to identify a unique backend service port
• Ingress rules use the path prefix to route to a backend service port
• Example
  • trafficparrot.xyz.com points to Ingress controller IP 1.2.3.4 using static DNS entry
  • trafficparrot.xyz.com/service1/http Ingress path prefix maps to backend service1 port 1234
  • trafficparrot.xyz.com/service1/https Ingress path prefix maps to backend service1 port 4567
  • trafficparrot.xyz.com/service2/http Ingress path prefix maps to backend service2 port 1234
  • https://kubernetes.io/docs/concepts/services-networking/ingress/#simple-fanout

Option B - Wildcard domain with unique Ingress host mappings

• DNS server points wildcard domain record to static Ingress controller IP
• Unique domain names are used to identify a unique backend service port
• Ingress rules use the host field to route to a backend service port
• Example
  • *.trafficparrot.xyz.com points to Ingress controller IP 1.2.3.4 using wildcard DNS entry
  • service1-http.trafficparrot.xyz.com Ingress host maps to backend service1 port 1234
  • service1-https.trafficparrot.xyz.com Ingress host maps to backend service1 port 4567
  • service2-http.trafficparrot.xyz.com Ingress host maps to backend service2 port 1234
  • https://kubernetes.io/docs/concepts/services-networking/ingress/#name-based-virtual-hosting

Traffic Parrot 5.23.0 released, what's new?

We have just released version 5.23.0. Here is a list of the changes that came with the release:

Features

• Initial release of Traffic Parrot workstation client (beta):
  • The workstation (beta) is part of a new client-server product offering for customers
  • Traffic Parrot workstation clients create virtual services and save configuration files
  • Traffic Parrot servers run virtual services using the configuration files created by the clients
  • Configuration files can be stored and retrieved from version control systems or artifact repositories
• Initial support for using multiple HTTP/HTTPS ports linked to separate mappings (beta):
  • New virtual services (beta) page to view/add/edit/delete virtual services
  • A distinct HTTP/HTTPS port may be assigned per virtual service
  • Only one virtual service can be edited at a time by selecting from the dropdown
  • The home page now lists all virtual service names and ports
  • Configuration is currently stored in scenarios/VirtualServiceName/service.properties directory structure
  • Increasing the number of virtual services will have a direct impact on memory usage of the server
  • Consider increasing your jvm.args configuration heap size -Xmx128m if you plan to use multiple virtual services per Traffic Parrot instance
• New arithmetic operations in dynamic responses

Fixes

• Fixed an issue where the navigation bar overlapped the main content on some smaller screen sizes
• Fixed an issue where transformer names would be duplicated in mapping files on save