-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable Envoy proxy sidecar to terminate TLS traffic and initiate a mTLS connection with the other sidecars in the mesh #21368
Comments
subscribe |
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. |
This didn't make it into 1.6. Moving to 1.7 where it will have to be re-evaluated. |
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 |
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 |
@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 ? |
🚧 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. |
@costinm Can you explain this? what exactly I need to run envoy as Gateway next my app? |
@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 |
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? |
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
The text was updated successfully, but these errors were encountered: