Enable Envoy proxy sidecar to terminate TLS traffic and initiate a mTLS connection with the other sidecars in the mesh

[daymasanket]

Describe the feature request

We are a major financial organization that leverages micro-services in a Kubernetes cluster communicating with each other using TLS currently (Note - not mutual auth).
 
The problem we are trying to solve is that we would like to make use of mTLS capabilities of Istio, between micro-services and using SSL between the micro-service container and the Envoy Proxy sidecar.
 
In this scenario, we would also like to be able to scrape HTTP metrics at the envoy sidecar for observability.
 
Use case: Service A calling Service B.
 
Current approach: Service A initiates a one-way TLS connection, which is terminated at the Envoy sidecar.  Envoy proxy sidecar of Service A then initiates a mTLS connection with the envoy proxy of Service B.  And then, the envoy proxy of Service B terminates the mTLS connection and initiates a one-way TLS with Service B container using self-signed certs.
 
Service A --> TLS --> Envoy Proxy of Service A --> mTLS --> Envoy Proxy of Service B --> TLS --> Service B
 
For enabling this capability in Istio, we are extending Istio by making use of the custom EnvoyFilter configuration as seen in the code block below.
 
Ideally, we would like have this capability built into Native Istio to avoid having to use custom EnvoyFilter configurations.  Custom configurations can go out of date quickly in a version upgrade, and require special maintenance between versions.
 
If this could be built into Native Istio, we can avoid having to do this.

---

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: custom-envoy-filter
spec:
  configPatches:
    - applyTo: CLUSTER
      match:
        context: SIDECAR_INBOUND
        cluster:
          portNumber: 443
      patch:
        operation: MERGE
        value:
          transport_socket:
            name: tls
            typed_config:
              "@type": type.googleapis.com/envoy.api.v2.auth.UpstreamTlsContext
              common_tls_context:
                tls_certificates:
                  - certificate_chain:
                      filename: /etc/certs/custom/cert.pem
                    private_key:
                      filename: /etc/certs/custom/key.pem
                validation_context:
                  trusted_ca:
                    filename: /etc/certs/custom/ca-chain.cert.pem
    - applyTo: FILTER_CHAIN
      match:
        context: SIDECAR_OUTBOUND
        listener:
          portNumber: 443
      patch:
        operation: MERGE
        value:
          transport_socket:
            name: tls
            typed_config:
              "@type": type.googleapis.com/envoy.api.v2.auth.DownstreamTlsContext
              common_tls_context:
                tls_certificates:
                  - certificate_chain:
                      filename: /etc/certs/custom/cert.pem
                    private_key:
                      filename: /etc/certs/custom/key.pem
                validation_context:
                  trusted_ca:
                    filename: /etc/certs/custom/ca-chain.cert.pem
 
Here the custom certs are mounted in the sidecar proxies using the Istio annotations.
 
Describe alternatives you've considered
 
As described above, we are using the EnvoyFilter configuration available in Istio to accomplish this task.
 
 
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ X ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ X ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
 
Additional context
 

[linsun]

subscribe

[incfly]

I think this is the main user feature request of the sidecar API? @rshriram would be nice to compile all PRs ref this one. Or duped this one closed.

[jacob-delgado]

This didn't make it into 1.6. Moving to 1.7 where it will have to be re-evaluated.

[costinm]

I'm not sure why you want to use a sidecar - what you are describing is a Gateway. Do you need the envoy to be running
alongside an app ? Technically this should work - with changes to the injection template or manual injection - we can make it easier if it's common, but running an envoy configured as Gateway next to a workload is possible, and is pretty similar with 'whitebox' mode where iptables are not used.

[Aenima4six2]

Chiming in here because this is related to my Envoy and Istio objectives. I think the benefits of using a sidecar over a gateway is the simplicity granted to the application container, allowing it to be completely ignorant of TLS from a hosting perspective, while ensuring that no unencrypted traffic flows across a node (only within a pod). One of my objectives was to allow for simple or mTLS between all pods communicating within the mesh, with the sidecar terminating TLS when it proxies the call into the application container. If possible, it would obviate the need for our developers to add any kind of TLS support at the application level.

[manmaujin2]

@sanketdayma96 , may I know how can you inject the cert into the envoy proxy ? Are you manually inject the cert into the envoy proxy into container or have any other setting to config envoy proxy can inject cert when deploy ?

[daymasanket]

@sanketdayma96 , may I know how can you inject the cert into the envoy proxy ? Are you manually inject the cert into the envoy proxy into container or have any other setting to config envoy proxy can inject cert when deploy ?

I created a configmap consisting of the certs and mounted it in the sidecar using the userVolume and userVolumeMount annotations. Hope this helps.

[manmaujin2]

@sanketdayma96 , may I know how can you inject the cert into the envoy proxy ? Are you manually inject the cert into the envoy proxy into container or have any other setting to config envoy proxy can inject cert when deploy ?

I created a configmap consisting of the certs and mounted it in the sidecar using the userVolume and userVolumeMount annotations. Hope this helps.

Thanks you! I have success to insert the cert into sidecar proxy. For MTLS between A and B istio proxy, are you apply the PeerAuthentication , AuthorizationPolicy and the envoy filter then can enable the HTTPS between istio proxy ?

[istio-policy-bot]

🚧 This issue or pull request has been closed due to not having had activity from an Istio team member since 2020-07-14. If you feel this issue or pull request deserves attention, please reopen the issue. Please see this wiki page for more information. Thank you for your contributions.

Created by the issue and PR lifecycle manager.

[Arsen-Uulu]

I'm not sure why you want to use a sidecar - what you are describing is a Gateway. Do you need the envoy to be running alongside an app ? Technically this should work - with changes to the injection template or manual injection - we can make it easier if it's common, but running an envoy configured as Gateway next to a workload is possible, and is pretty similar with 'whitebox' mode where iptables are not used.

@costinm Can you explain this? what exactly I need to run envoy as Gateway next my app?

[Arsen-Uulu]

@sanketdayma96 Hey, I am trying to use your filter for the same purpose, but for some reason envoy is not terminating SSL from my Service A to Service B. Sidecar is doing Passthrough since the traffic encrypted not by sidecar

[priyanka-operant]

What is the status on this issue of sidecar being deployed in hybrid mode? I see that the PRs have been merged. Is it now available in an Istio version?
I was also looking for guidance on how to configure the Envoy sidecar in this new hybrid mode to terminate TLS on the egress path and originate mTLS / simple TLS to the destination service like this: ( Service A --> simple TLS --> sidecar Envoy on outbound path (terminates) --> initiates new simple tls to external service --> external service ) . Is there sample documentation for how to achieve this sidecar configuration? The primary use case here is to get telemetry data for the original requests.