Disabling mTLS Between Gorouter and Envoy Sidecar in Tanzu Application Service
Article ID: 407122
Updated On:
Products
Issue/Introduction
We want to evaluate certain aspects of Tanzu Application Service (TAS) deployment, specifically regarding the network communication between the Gorouter and application containers.
According to the documentation, TAS uses TLS or mTLS by default for traffic between the Gorouter and the Envoy sidecar injected into each app container, which improves security and trust between components.
Running the same set of applications in both TAS and TKGI (Kubernetes) environments. The development teams have observed that application response times are significantly faster in TKGI, where the traffic path is more direct and less layered.
How TLS/mTLS overhead in TAS may be contributing to latency, especially in scenarios with many small or high-throughput requests.
Is it possible to disable or relax the mTLS requirement between the Gorouter and Envoy sidecar, purely for performance testing and benchmarking purposes.
Is there any supported or experimental method to disable or bypass TLS/mTLS for Gorouter-to-Envoy communication?
Are there any BOSH properties, ops files, or feature flags that control this behavior?
What are the potential implications or limitations of doing so?
Environment
TAS 6.x
TKGi 1.22
Cause
TLS between the gorouter and the App cannot be disabled but only changed between mTLS (verifying bosh client and server) that will introduce higher delay and TLS which is performing less check (only server verification)
There is no direct way that can disable the TLS between gorouter and APP.
Resolution
Having larger number of routers and instances in case of 9 routers and 10 instances will require about 90 requests that will establish each router to each instance tls session - this is the initial session taking place once the session is established it will keep the session alive for 90 Seconds, if there is no consecutive requests the tls session will be terminated at the 90 sec timeout. https://docs.cloudfoundry.org/adminguide/routing-keepalive.html
During testing you have noticed that you needed between 22 and 28 requests to be able to reach out to all routers which is expected as there are other clients from other application that potentially hit same loadbalancer at the same time you are running tests, it is possible that same router might be skipped form your test during the first iterations (10 requests) due to round robin might serve another request and this will lead to skipping a router at this interaction.
when running for longer period and more requests the average load on the go routers is almost equal however some small fluctuations are expected.
In order to test your application directly to one gorouter you can try the following approach in my sample I am using a
cf apps
Getting apps in org system / space system as admin...
name requested state processes routes
...
drop-con started web:1/1 drop-con.lab12apps-tanzu-gss.labtest.local
...
Get the go router IPs
bosh vms | grep router
router/90a1cf90-2080-435c-b47d-63f20a001ad6 running az1 10.xxx.xxx.69 vm-b6c93558-362d-42c1-abe1-15168a22e6cb micro.ram true bosh-vsphere-esxi-ubuntu-jammy-go_agent/1.866
Export the URL you wanna use
URL=https://drop-con.lab12apps-tanzu-gss.labtest.local/hi
Test the request first as the below loop only shows the time for completion and any actual outputs are silenced
curl -k -v --resolve drop-con.lab12apps-tanzu-gss.labtest.local:443:10.xxx.xxx.69 -w "DNS: %{time_namelookup}s Connect: %{time_connect}s TTFB: %{time_starttransfer}s Total: %{time_total}s\n" "$URL"
in my example app I should see answer Hi! this indicates that my request is completed successfully using -v -k options from above and removing -s and -o /dev/null gives me opportunity to confirm my request is working in your case you might have to add -X POST and -d <BODY>
Make the ajdustents to the curl request below and if needed reduce the sleep interval to suitable params then execute the request if you have routing access to the gorouter this will bypass all NSX LBs and hit directly the gorouter you would like for alternative measure of speed.
for i in {1..60}; do echo "Request #$i"; curl -k -s --resolve drop-con.lab12apps-tanzu-gss.labtest.local:443:10.xxx.xxx.69 -o /dev/null -w "DNS: %{time_namelookup}s Connect: %{time_connect}s TTFB: %{time_starttransfer}s Total: %{time_total}s\n" "$URL"; sleep 1; done
Request #1
DNS: 0.000027s Connect: 0.000481s TTFB: 0.022439s Total: 0.022554s
Request #2
DNS: 0.000025s Connect: 0.000553s TTFB: 0.018993s Total: 0.019086s
Request #3
DNS: 0.000026s Connect: 0.000690s TTFB: 0.017406s Total: 0.017518s
On the initial question can TLS be disabled between the go router and the APP instance the answer is no you can only change the TLS type ( Mutual TLS or just TLS (without client verification) both method will introduce some initial delay but if there are consecutive requests that are within the timeout interval the TLS session will be reused.
Feedback
