envoy
envoy copied to clipboard
envoyproxy
[PoC][Draft] TLS Bumping integration
NOT READY FOR REVIEW
This PR is to merge following parts, and do integration test on release_v1.23.
Certificate Provider framework https://github.com/envoyproxy/envoy/pull/19582 SNI-based cert selection in tls transport socket https://github.com/envoyproxy/envoy/pull/22036 A new network filter - BumpingFilter https://github.com/envoyproxy/envoy/pull/22582 Certificate Provider instance - LocalMimicCertProvider https://github.com/envoyproxy/envoy/pull/23063
Signed-off-by: Luyao Zhong [email protected] Signed-off-by: LeiZhang [email protected]
As a reminder, PRs marked as draft will not be automatically assigned reviewers, or be handled by maintainer-oncall triage.
Please mark your PR as ready when you want it to be reviewed!
:cat:
Caused by: https://github.com/envoyproxy/envoy/pull/23192 was opened by LuyaoZhong.
![repokitteh-read-only[bot] avatar](https://avatars.githubusercontent.com/in/16729?v=4 "Published by a pub.dev verified publisher"){kind=small}
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @mattklein123
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).
CC @envoyproxy/dependency-shepherds: Your approval is needed for changes made to (bazel/.*repos.*\.bzl)|(bazel/dependency_imports\.bzl)|(api/bazel/.*\.bzl)|(.*/requirements\.txt)|(.*\.patch).
envoyproxy/dependency-shepherds assignee is @moderation
:cat:
Caused by: https://github.com/envoyproxy/envoy/pull/23192 was opened by LuyaoZhong.
CC @envoyproxy/runtime-guard-changes: FYI only for changes made to (source/common/runtime/runtime_features.cc).
:cat:
Caused by: https://github.com/envoyproxy/envoy/pull/23192 was synchronize by LuyaoZhong.
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!
@LuyaoZhong in your design and implementation, is it expected that the TCP proxy/HCM would re-use the connection that was opened for fetching the certificate? Or would Envoy end up with 2 upstream connections per 1 downstream request that includes mimicking?
n your design and implementation, is it expected that the TCP proxy/HCM would re-use the connection that was opened for fetching the certificate? Or would Envoy end up with 2 upstream connections per 1 downstream request that includes mimicking?
We will not re-use the connection. So envoy would have 2 upstream connections per 1 downstream request if mimicking is required. And when corresponding mimic cert is ready, we don't need addition upstream connection, then it will be 1 upstream connection per 1 downstream request. But we hope it can re-use if it doesn't need dramatic change, do you have any suggestions?
Would you mind share your use case?
My use case is somewhat similar, but instead of having Envoy do the mimicking, I would like to query an external service that would do the mimicking and respond with a certificate. The problem I had in mind was that if an external service does this, then there would be no re-use of connections, and we'll end up with 2 TCP streams per 1 downstream request. However, seems like there's no better option at this time and supporting this on Envoy would be very expensive.
In my case I'm investigating the option to integrate this as part of the SDS. Meaning that if a secret is unknown at TLS handshake time, Envoy will pause the handshake and call SDS to fetch the certificate on-demand. Then, since SDS is external service, it can do whatever it wants at the time the request for fetch was invoked. It can either respond with yet-provided secret (that is known to SDS), or it can have logic to do mimicking on the fly. Since you were doing some work on this, I was hoping to get your ideas on this method and has this been looked into.
Current problem with SDS is that it does not support "Give me all you have" or "Fetch on-demand" features. You have to subscribe to a named resource statically and SDS will only provide secrets for these subscriptions. Further context: https://github.com/envoyproxy/envoy/issues/25958
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!
This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!