You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are constantly coming across scenarios in VM deployments where certificates per app are mounted onto the VMs. The existing services terminate HTTPS at the application layer. When introducing a sidecar in this scenario, if we wish to maintain transparency of the mesh, we need the sidecar to be able to terminate HTTPS in the inbound path and also be able to initiate HTTPS from the sidecar to the app on the localhost.
We could augment the Sidecar's Ingress section to be able to specify the certs for the ingress as well as a toggle indicating the need to do https in the default endpoint. This however does not align with the fact that the VM's service is declared in a service entry [which determines the default inbound paths] and the sidecar then declares additional properties of the service ports. So another alternative would be to define the ingress certs on the service entry. And a final not so clean alternative is to make each VM service a gateway so that we can define inbound HTTPs with certs with some hacks for sidecar to app https. Such a model does not scale when we have to handle large numbers of VM services that could also have east to west communication.
cc @louiscryan
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[x ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
Additional context
The text was updated successfully, but these errors were encountered:
We are constantly coming across scenarios in VM deployments where certificates per app are mounted onto the VMs. The existing services terminate HTTPS at the application layer. When introducing a sidecar in this scenario, if we wish to maintain transparency of the mesh, we need the sidecar to be able to terminate HTTPS in the inbound path and also be able to initiate HTTPS from the sidecar to the app on the localhost.
We could augment the Sidecar's Ingress section to be able to specify the certs for the ingress as well as a toggle indicating the need to do https in the default endpoint. This however does not align with the fact that the VM's service is declared in a service entry [which determines the default inbound paths] and the sidecar then declares additional properties of the service ports. So another alternative would be to define the ingress certs on the service entry. And a final not so clean alternative is to make each VM service a gateway so that we can define inbound HTTPs with certs with some hacks for sidecar to app https. Such a model does not scale when we have to handle large numbers of VM services that could also have east to west communication.
cc @louiscryan
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[x ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
Additional context
The text was updated successfully, but these errors were encountered: