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.